mentor

claude-workbench

繁體中文

A family of Claude Code plugins that turn the CLI into a persistent, event-driven AI workspace. Install one, two, or all of them — each plugin is useful on its own, and they reinforce each other when combined.

Status: v0.1.0 (Draft). kanban, notify, and docsync are shipped; memory is the remaining core stub. See SPEC.md for the full design and current_state.md for the live implementation snapshot.

Quickstarts: kanban · notify · mentor (docsync was replaced by mentor — see epic/mentor-plugin-spec.md)

Plugins

Plugin	Profile	Solves	Status
kanban	core	Task state persistence + shared human/AI work queue via kanban.json	v0.1.0 ready
notify	core	Push notifications (Pushover) when Claude needs your attention	v0.1.0 ready
memory	core	Cross-session RAG memory (SQLite + embeddings, local only)	v0.0.1 stub
mentor	dev	Onboarding mentor — prescribes bootstrap docs, Epic/Sprint/Issue/ADR hierarchy, agent workflow (replaces docsync)	v0.1.0 ready
workbench	—	★ Core bundle (kanban + notify + memory)	meta, stub
workbench-dev	—	★ Dev bundle (workbench + docsync)	meta, stub

Install individually for progressive adoption, or install the meta-bundles once memory v0.1.0 also lands.

Why

Typical Claude Code usage is session-scoped: open session → give instructions → wait → close. Context evaporates, there is no persistent task queue, no event-driven triggers, no shared state across machines, no accumulated knowledge.

Workbench solves these four pains as three independent plugins that compose:

1. State persists — kanban.json at the project root is the single source of truth.
2. Events trigger Claude — cron / git hooks / webhooks drive headless claude -p.
3. Claude can reach you — Pushover (et al.) push when decisions are needed.
4. Knowledge accumulates — per-project RAG memory, auto-injected on session start.

Install

# 1. Start Claude Code in any project
cd my-project
claude

# 2. Add the marketplace (public repo; use the SSH URL for private)
> /plugin marketplace add kirinchen/claude-workbench

# 3. Install what you need
> /plugin install kanban@claude-workbench       # ready
> /plugin install notify@claude-workbench       # ready (Pushover)
> /plugin install mentor@claude-workbench       # ready (dev profile, replaces docsync)
> /plugin install memory@claude-workbench       # coming soon
> /plugin install workbench@claude-workbench    # bundle (when memory ships)

Then jump into the quickstart for each plugin you installed — see the links at the top of this file.

No shell rc editing required. Hook scripts and slash commands auto-prepend ~/.claude-workbench/bin to PATH when they run, and notify reads tokens from ~/.claude-workbench/.env (written by /notify:setup). Add export PATH="$HOME/.claude-workbench/bin:$PATH" only if you want to run workbench-* CLIs manually from your terminal for debugging.

Two identifiers, one letter apart

The install flow uses two separate names that happen to look similar. Getting them mixed up is the most common new-user mistake:

Step	What it references	Where it comes from
/plugin marketplace add kirinchen/claude-workbench	GitHub repo (auto-expands to https://github.com/kirinchen/claude-workbench)	Your GitHub owner/repo path
/plugin install kanban@claude-workbench	Marketplace name — the "name" field inside .claude-plugin/marketplace.json	Set in the marketplace metadata, not the repo name

They're equal today by choice. If the repo were ever renamed to cwb, the add command would become kirinchen/cwb but install would still be kanban@claude-workbench (until the marketplace.json's name field is also changed). Other accepted add sources: full HTTPS URL, SSH URL (for private), local path — see Claude Code plugin marketplaces.

Quickstart — kanban

> /kanban:init --with-examples      # seed kanban.json + schema
> /kanban:status                    # read-only summary
> /kanban:next                      # pick a TODO and move it to DOING
> /kanban:done --note="deployed"    # close the DOING task

What Claude will and will not do with kanban.json:

Will:

• Respect depends — never start a task with unresolved dependencies.
• Follow priority order (meta.priorities, P0 first by default).
• Append comments on the task rather than guessing when ambiguous.
• Auto-commit kanban transitions as standalone commits.