Stats
Links
Categories
Work lifecycle management plugin for Claude Code
npx claudepluginhub popoffvg/claude-plugin-work-managerWork lifecycle management — start, track, recall, complete, and PR creation for tasks.
Work lifecycle management plugin for Claude Code. Start, track, recall, and complete development tasks with automatic progress logging and knowledge capture.
_notes/ as their main output, not a side-effect1. Create workspace mise run task # interactive: pick repos, create worktrees
cd tasks/MILAB-1234-fix-auth/
2. Start tracking /work start # creates _notes/, detects branch, gathers scope
3. Research phase (ask questions, explore code)
→ auto-saves findings to _notes/research-*.md
4. Plan phase /work update move to plan
→ build task list, acceptance criteria in _notes/
5. Implement phase /work update move to implement
→ write code, run tests, results in _notes/impl-*.md
6. Iterate /work recall # re-orient: what's done, what's next
/work update <message> # log progress, capture knowledge
7. Finish /work done # verify criteria, mark complete
/work pr # create PRs across all affected repos
8. Cleanup mise run task-remove # detach worktrees, delete task folder
Mise tasks are optional — the core plugin (/work start, /work recall, etc.) works in any git repo.
| Capability | With mise tasks | Without mise tasks |
|---|---|---|
| Branch management | Automatic worktrees per repo | Manual git checkout -b |
| Repo isolation | Each task gets its own working tree | Shared working tree, stash to switch |
| Task creation | mise run task (interactive fzf) | Create branch + cd + /work start |
| Task cleanup | mise run task-remove (auto worktree detach) | Manual branch deletion |
| MCP config | Auto-copied .mcp.json per worktree | Manual setup |
| Multi-repo | Select multiple repos in one step | Set up each repo individually |
| Command | Description |
|---|---|
/work install | Guided setup — plugin, QMD, mise, task scripts |
/work start | Initialize a work session — creates _notes/ with _summary.md and work notes |
/work status | Show current work summary |
/work recall [topic] | Re-orient to current work with dynamic knowledge loading |
/work recall --deep | Load everything for comprehensive context |
/work update <message> | Log progress, capture knowledge, or transition phase |
/work done | Mark work as complete |
/work pr | Create PRs for all repos with unpushed commits |
/work help | Show usage guide |
User → work-manager (router) → reads phase from _notes/_summary.md
→ skill commands: executes directly
→ phase work: delegates to phase agent
→ transitions: updates _summary.md
Phase agents:
work-researcher (green) — Read, Glob, Grep, Bash (r/o), Explore agents, Write (_notes/ only)
work-planner (yellow) — Read, Glob, Grep, Bash (r/o), Write (_notes/ only)
work-implementer (red) — All tools, spawns code subagents
Phase skills (loaded by agents on demand):
work-research — scope breakdown, exploration workflow, findings template
work-plan — acceptance criteria, task lists, work split, decision template
work-implement — task execution, test runs, results template, blocker handling
Why three agents? The tools field in agent frontmatter is hard enforcement — the agent physically cannot call tools not listed. A single agent with prompt-based restrictions fails because models ignore behavioral constraints when focused on the user's request.
Why phase skills? Skills describe what to do (workflow steps, file templates, writing rules, completion signals). Agents define how to do it (tool access, delegation strategy). This separation keeps agents lean and allows progressive disclosure — skill content loads only when the phase activates.