open-index/open-npm huggingface dataset:
npm package: @howaboua/opencode-workflows-tool
Description: Enhanced skill tool plugin for OpenCode - 1:1 clone of built-in skill tool with extensibility
Author: Igor Warzocha
Latest version: 0.0.6

# Opencode Workflows Tool (aka skills but better)

An addition to OpenCode’s `skill` tool that helps agents capture repeatable SOPs and reuse them across sessions, including a `workflow-create` tool with YAML frontmatter protection.

Why? Agents tend to dislike the word “skill". They think they've already got all the skills necessary to perform the task. This plugin reframes that behavior around **workflows/SOPs** and enables agents to create and refine repo-standard-workflows during long-running sessions. Given it's hot-reload, it also works across subagents. If your subagent defines a workflow, it will appear as reusable across all the running sessions/subsessions.

Why not global? A bit opinionated, but I believe *skills* should be global, and carefully selected to be used *only* by specific agents to avoid context rot. And not every skill will apply to every project you're working on.

## Features

- **Bundled Skill**: Ships with a `workflows` skill that teaches agents when and how to use workflows effectively
- **Slash Command**: `/workflow` to automatically document a session as an SOP and associate it with a directory via `AGENTS.md`
- **Tools exposed**: `workflows` and `workflows_create` for listing, loading, and creating SOPs
- **Workflow discovery**: Scans `.opencode/workflows/**/WORKFLOW.md` in the current repo
- **Workflow creation**: `workflows_create` writes new workflows from structured name/body input
- **System prompt injection**: Always exposes `<available_workflows>` to the main agent and subagents
- **Nested context**: Supports directory-specific workflow suggestions via auto-loaded `AGENTS.md` files
- **Hot reload friendly**: New workflows are discoverable immediately during ongoing sessions

<img width="1024" height="559" alt="image" src="https://github.com/user-attachments/assets/635cc97b-a7f7-496e-97fe-6b7d83c536ae" />

## Installation

Add to your repo `opencode.json` or `.opencode/opencode.jsonc` (preferred):

```jsonc
{
  "plugin": ["@howaboua/opencode-workflows-tool@latest"],
}
```

Or reference a local plugin file:

```jsonc
{
  "plugin": ["file:///absolute/path/to/your/plugin/src/index.ts"],
}
```

## Usage

### Slash Command

The `/workflow` command is the fastest way to capture work. It instructs the model to analyze the current session, document it using `workflows_create`, and suggest the new workflow to future agents by adding a rule to a nested `AGENTS.md`.

```
/workflow
```

### Tools

List available workflows:

```
Use the workflows tool with no arguments to list available workflows.
```

Load a workflow:

```
Use the workflows tool with workflow: "release-checklist".
```

Create a new workflow manually:

```
Use workflows_create with name: "release-checklist" and body containing the SOP steps.
```

## Development

```bash
# Install dependencies
bun install

# Build (Linux/macOS only)
bun run build

# Watch mode
bun run dev
```

## License

MIT
npm package: @howaboua/pi-glm-via-anthropic
Description: Use Z.ai GLM models in pi through Z.ai's Anthropic-compatible endpoint.
Latest version: 0.1.1

# @howaboua/pi-glm-via-anthropic

Use Z.ai GLM models in [pi](https://pi.dev/) through Z.ai's Anthropic-compatible endpoint.

It overrides pi's built-in `zai` provider to send requests to `https://api.z.ai/api/anthropic`.

## Why

This package exists because many GLM Coding Plan users prefer Z.ai's Anthropic-compatible route over the default coding endpoint.

Why:

- Z.ai officially exposes an Anthropic-compatible endpoint for coding tools.
- Z.ai's Claude Code docs describe that setup around "Code faster" and "rock-solid reliability".
- Community reports and benchmarks commonly describe the Anthropic route as faster, lower-latency, or less flaky than the default coding endpoint.

## What it does

- keeps the provider name as `zai`
- reuses your existing Z.ai credentials in pi
- switches pi to the Anthropic-compatible transport for these models:
  - `zai/glm-5.1`
  - `zai/glm-5-turbo`
  - `zai/glm-4.7`
  - `zai/glm-4.5-air`

## Install

```bash
pi install npm:@howaboua/pi-glm-via-anthropic
```

Project-local install:

```bash
pi install npm:@howaboua/pi-glm-via-anthropic -l
```

One-off usage without installing:

```bash
pi -e npm:@howaboua/pi-glm-via-anthropic
```

## Credentials

If you already use Z.ai in pi, you probably do not need to do anything.

This package keeps the provider name as `zai`, so pi continues using the normal Z.ai credential sources:

1. `~/.pi/agent/auth.json`
2. `ZAI_API_KEY`

Example `auth.json` entry:

```json
{
  "zai": { "type": "api_key", "key": "your-zai-key" }
}
```

Or use an environment variable:

```bash
export ZAI_API_KEY=your-zai-key
```

## Remove

```bash
pi remove npm:@howaboua/pi-glm-via-anthropic
```

## Optional override

If you want to point the adapter at a different Anthropic-compatible base URL, set:

```bash
export ZAI_ANTHROPIC_BASE_URL=https://your-proxy.example.com
```

## References

- Z.ai Claude Code guide: https://docs.z.ai/devpack/tool/claude
- Z.ai third-party tool guide: https://docs.z.ai/guides/development/using-glm-api-with-third-party-tools
- Roo Code issue discussing faster results via `https://api.z.ai/api/anthropic`: https://github.com/RooCodeInc/Roo-Code/issues/8488
- Community discussion: https://www.reddit.com/r/ZaiGLM/comments/1rti3cy/psa_for_legacy_users_with_no_active_sub/
- pi package docs: https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/docs/packages.md
npm package: @howaboua/pi-howaboua-extensions-primitives-sdk
Description: WIP Pi extension primitives SDK for consistent TUI views
Author: howaboua
Latest version: 0.3.0

> ⚠️ **WIP / personal-use package**
>
> This SDK is currently for use by **howaboua** to standardize personal Pi extensions.
> You can use it, but you do so at your own peril 😄

# Pi Extensions Design SDK

A reusable SDK for building consistent, high-signal TUI views in Pi extensions.

## What this gives you

- fixed-height panels with consistent headers/footers
- list/action/detail flows with shared interaction patterns
- attached detail previews above the main panel
- turnkey picker runtime for one-off selections (`runPicker`)
- turnkey multiline composer runtime for prompt/text editing (`runComposer`)
- wraparound navigation and predictable key behavior

## Repo layout

- `./sdk` → framework-style SDK source
- `./sdk/example` → frozen reference implementation

## Quick start

1. Import SDK primitives from `@howaboua/pi-howaboua-extensions-primitives-sdk` in your Pi extension code.
2. Build your screens with the exported primitives.
3. Register your command and call the shared runtime loop.

For API contracts and usage details, read:

- `./AGENT_REFERENCE.md` (agent-first integration contract)
- `./API_REFERENCE.md` (fast export/signature map)
- `./sdk/README.md` (SDK internals and roles)

## Migration helper

From this SDK repository checkout, rewrite local `./sdk` style imports to the npm package automatically:

```bash
npm run migrate:sdk-imports -- /path/to/extension
```

## Notes

- `./sdk/example` is reference code and intended to stay stable.
- SDK changes should be intentional and minimal.
- Optional live preview: point Pi directly to `./sdk/example/index.ts`.
npm package: @howaboua/pi-todomaster
Description: TodoMaster extension for Pi
Latest version: 0.1.0

# pi-todomaster

`pi-todomaster` adds a checklist-first planning system to Pi.

It provides an interactive `/todo` UI for managing three document types:

- PRDs
- specs
- todos

## What you can do

- create PRD/spec/todo plan files under `.pi/plans`
- open focused list views for tasks, PRDs, specs, and closed items
- run work/refine/review flows from the action menu
- attach and validate bidirectional links between related plan files
- edit todo checklists directly from the UI
- claim/release assignment per session
- use a standardized SDK-based TUI shell shared across extensions
- mark items as `ralph-loop` or `ralph-loop-linked` and stage a canonical loop command from the action menu

## Checklist and status model

For todo items, checklists are the primary progress signal:

- todos MUST include a non-empty checklist on create
- checking items updates progress deterministically
- status is derived from checklist completion for checklist-based work

## Keyboard workflow highlights

- list views:
  - `j/k` or arrows to move
  - `Enter` to open actions
  - `/` to search
  - `Ctrl+X` to open **More options** (auto-timeout)
  - `Tab` / `Shift+Tab` cycle list panes
- detail/actions:
  - `j/k` move through actions
  - `v` toggles attached detail preview
  - preview uses `J/K` for scrolling
  - `Esc` returns back
- create/edit inputs:
  - `Enter` submits
  - `Shift+Enter`, `Ctrl+Enter`, or `Alt+Enter` inserts new lines

## Storage

Plan files are stored in:

- `.pi/plans/prds`
- `.pi/plans/specs`
- `.pi/plans/todos`

Each item is markdown with frontmatter and uses `type` (`prd`, `spec`, `todo`) for classification.

## Install

```bash
pi install npm:@howaboua/pi-todomaster
```

Local package development:

```bash
npm install
npm run build
```

## Publish on npm

This package is configured for public npm publishing and Pi registry discovery:

- `keywords` include `pi-package` and `pi-extension`
- `publishConfig.access` is set to `public`
- the published tarball includes the source extension entrypoint plus the built Node CLI helper under `dist/`

Useful commands:

```bash
npm run publish:dry-run
npm run publish:dev
npm run release:dev
```

Typical release flow:

```bash
npm login
npm run publish:dry-run
npm publish
```