From team-tracking-mcp
Use when turning a goal/PRD into board state — reading the existing board, choosing hierarchy + priority, decomposing tasks into pipeline subtasks, and handing off to specialists. Covers what to put on the board and in what order. Pairs with `team-tracking-supervise` (after the dispatch).
How this skill is triggered — by the user, by Claude, or both
Slash command
/team-tracking-mcp:team-tracking-planThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You're the planner. You turn intent into structure: read the existing board, decide hierarchy, decompose, dispatch. You **don't** write code, **don't** acquire locks, and **don't** stay in the loop after dispatch — supervision is a separate skill ([`team-tracking-supervise`](../team-tracking-supervise/SKILL.md)).
You're the planner. You turn intent into structure: read the existing board, decide hierarchy, decompose, dispatch. You don't write code, don't acquire locks, and don't stay in the loop after dispatch — supervision is a separate skill (team-tracking-supervise).
This skill is loaded by the
team-tracking-plannersubagent. If you're in a main session and considering loading it directly, prefer spawning the agent instead — it owns this protocol and returns a structureddispatch_list, keeping board-reading and decomposition out of your context.
Lower-level tool reference: team-tracking-usage.
list_board(project)
The response is priority-ordered (In Progress → Todo → Backlog). Don't plan in a vacuum:
lock_state == "in_progress" — a specialist is actively working. Don't create overlapping work.lock_state == "committed" — work is in flight with a checkpoint. If lock.acquired_at is past TTL, it's a crash; surface to the user before stealing the lock.scope — free-text conflict signal. If your new ticket touches the same module, sequence behind (or split that module out first).branch — code is already moving. Coordinate, don't duplicate.The board has five columns; the meaningful state machine is:
Backlog ──plan──► Todo ──lock acquired──► In Progress ──PR opened──► In Review ──merged──► Done
▲
┌───── auto-flip when every child is Done ──────────────────────────┘
acquire_tickets — don't write it manually.release_ticket(..., final_status: "In Review") once the PR is open.The Backlog → Todo move is yours to make. A common mistake (it bit a real session): create tickets, attach subtasks, dispatch, and never promote the parent — the board ends up with everything still in Backlog because nothing downstream promotes it. Nothing does.
update_ticket(epicRef, { status: "Todo" }) // before adding child tasks
update_ticket(taskARef, { status: "Todo" }) // before adding child subtasks
update_ticket(taskBRef, { status: "Todo" }) // ditto
PRD shape → top-level type. The server enforces these parent rules.
| PRD shape | Top-level | Decompose into |
|---|---|---|
| Multi-slice feature | epic | stories |
| Single feature | story | tasks |
| One-off change | task | pipeline subtasks |
epic parent: null
story parent: epic | null
task parent: story | epic | null
subtask parent: task | story
A task without subtasks is incomplete planning. Every task gets pipeline subtasks before dispatch.
| Stage | Required? | When to skip |
|---|---|---|
| Write tests | Optional (TDD opt-in) | Truly throwaway / unverifiable changes |
| Adversarial test review | Optional (only with tests) | Trivial test surfaces |
| Implement | Required | — |
| Spec compliance review | Optional | Self-contained UI tweaks where the spec is a Figma file |
| Adversarial code review | Required (≥1) | — |
Pick more stages (and multiple reviewers) for: auth, billing, migrations, public API changes, anything cross-cutting. Pick fewer for: self-contained UI, plumbing inside an existing pattern, spikes (often investigate → write findings → peer review).
| When | |
|---|---|
P0 | Regression, data loss risk, security, or blocks the release |
P1 | On the critical path for the next sprint |
P2 | Default. Want-not-need: cleanup, polish, deferred |
Don't promote unless the constraint is real. Priority isn't a signaling tool — lock_state already tells specialists what's hot.
Consult an architect (human or skill) before dispatching when:
Where to look for architectural context, in order:
architecture.md inside the project's vault folder (the obsidian-kanban adapter scaffolds this).ARCHITECTURE.md / CLAUDE.md at the repo root.You don't acquire locks. The specialist does. Your handoff is:
TicketRef plus a short brief: what "done" looks like, files in scope, links to spec, the parent task's body for context.team-tracking-execute — acquire → checkpoint → release. Acquiring the lock auto-flips the subtask to In Progress.team-tracking-supervise for the supervision protocol.Blocked, read the ticket's update + progress_summary and decide: split further, reassign, or escalate to user/architect.How you actually summon the specialist is host-specific — Claude Code's Agent tool, an external worker queue, a sub-agent CLI, an issue assignee in your tracker. This skill is agnostic to that mechanism. The only contract is: the specialist receives TicketRef, runs team-tracking-execute, and reports back via the events log.
update_ticket — when and howupdate_ticket is the only tool that mutates a ticket's mutable fields outside the lock contract (status, priority, scope, branch, pr_url, labels, body, title). Use it when you need to:
Todo before dispatchupdate_ticket(parentRef, { status: "Todo" })
Triggers card hoisting in the obsidian-kanban adapter. Every non-leaf child becomes its own card on the board.
When the implementer's branch is open and you can see the conflict surface, lock in the scope so future planners avoid double-booking the same module:
update_ticket(taskRef, { scope: "auth/middleware" })
branch and pr_url for visibilityThe specialist sets these as part of their normal flow, but if the orchestrator notices a missing wire-up (e.g. the specialist forgot, or you're stitching together a hand-off across sessions):
update_ticket(taskRef, {
branch: "feat/auth-retry-policy",
pr_url: "https://github.com/org/repo/pull/123",
})
Promote a P2 to P1 when it lands on the critical path — but only if the underlying constraint actually changed. Priority is a routing signal, not a nag.
update_ticket(taskRef, { priority: "P1" })
When supervision uncovers a sharper decomposition or a missing acceptance criterion, edit the body. Keep edits surgical — a long body that's been rewritten multiple times reads as confused planning.
update_ticket(taskRef, {
body: "## Updated plan after blocker on retry\n\n…",
})
update_ticket is not forstatus: "In Progress" yourself. That's auto on lock acquire.status: "Done" on a parent task. Auto-flip handles it; manual sets diverge from rollup state.update_ticket to record progress. Use report_progress (no lock needed) or commit_checkpoint (lock + SHA) — both flow through the event log so the supervisor sees them.The rules in this skill (column meanings, decomposition pipeline, priority semantics) are the canonical defaults. They're meant to be portable across projects. If your team or project deviates — different column names, an extra Staging column, skipping In Review, custom subtask roles — the right place for that knowledge is not another copy of these rules in your user-memory or somewhere else that future agents won't find.
The right places, in priority:
CLAUDE.md / AGENTS.md / GEMINI.md at the repo root or the relevant subdirectory. Per-project adaptations live with the project. Future agents loading the project will see them.If you find yourself encoding a workflow rule in user-memory because "the skill doesn't say it," either the skill should say it (PR upstream) or your project deviates from canon (CLAUDE.md). User-memory is the wrong substrate for shared workflow conventions — it doesn't follow the project, doesn't help your colleagues, and doesn't help next month's session in another project.
Todo → In Progress yourself. It happens automatically when a specialist acquires the lock.Backlog → Todo. That promotion is yours — it's the signal that you've decomposed the ticket and the children are ready to be picked up. Forgetting it leaves the whole tree marooned in Backlog.Done. Set the leaf subtask to Done; the adapter rolls the parent up when every sibling is also Done. Manual sets diverge from rollup state.scope strings inconsistently. Pick a vocabulary (typically module/package names) and stick to it.Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub razvanrotaru/team-tracking-plugin --plugin team-tracking-mcp