team-tracking-plugin

Use when you have at least one specialist in flight on a ticket and you need to keep them on track — listening to the event log, reading checkpoints, posting nudges/questions, recovering from stale locks. Pairs with `team-tracking-plan` (which got you here).

Use when you are the orchestrator on a team-tracking project. Routes to the role-specific skill — `team-tracking-plan` (decomposing intent into board state, dispatching specialists) or `team-tracking-supervise` (keeping in-flight specialists on track via the event log and steering channel).

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).

Use when your project's team-tracking adapter is `obsidian-kanban` and you need to understand the file layout, card-eligibility rule, default-status rule, sub-bullet rendering, or auto-flip behavior. Reference for surprises that don't show up in `team-tracking-usage` because they're adapter-specific. Skip when using Jira.

Reference for the team-tracking MCP server — the eleven tools, the four ticket types, the unified event log, the lock state machine, and the typed errors. Load this when you need to know what a tool does or how `lock_state` is derived. For role-specific protocols, use `team-tracking-plan` (planner, before dispatch), `team-tracking-supervise` (planner, after dispatch), or `team-tracking-execute` (specialist).

Use when you are a specialist subagent executing a single subtask (implementer, test-writer, adversarial reviewer, etc.). Covers acquiring the lock, recording a checkpoint after every git commit, the pulse-update protocol, and how to escalate work that's too complex back to the orchestrator instead of forcing it through.