Use when the user asks to discover tracks, dry-run eligible tracker stories, run autonomous multi-session workflow dispatch, watch orchestrator events, or analyze agentic-workflow-kit orchestrator runs. Reads .workflow/config.yaml plus references/tracker-contract.md and prefers the plugin-provided MCP runtime, with the CLI as a fallback. Do not use for writing PRDs, creating trackers, or implementing one story interactively.
Use when the user asks to pick, claim, implement, ship, or merge the next eligible agentic-workflow-kit tracker story, or names a specific tracker ID such as PC03, WK4, AR12, or TU11. Reads .workflow/config.yaml plus references/tracker-contract.md, discovers active trackers, validates dependencies and ownership, expands new story briefs into detailed technical story specs, writes implementation plans, then implements, verifies, updates tracker state, creates PRs, handles configured CI/review gates, optional merge, and cleanup. Do not use for creating trackers (use plan-delivery-track), writing PRDs (use define-product), or non-tracker one-off work.
Use when a repo wants to adopt agentic-workflow-kit, when the user says "init agentic-workflow-kit", "set up agentic-workflow-kit", "scaffold the workflow config", or runs /workflow-init. Detects the repo's package manager, verify command, CI, default branch, and branch-protection rules; chooses a PR/merge preset; writes .workflow/config.yaml; and scaffolds a tracks index plus an example tracker. Idempotent.
Use when a user wants to define a product before technical planning — when they say "write a PRD", "spec the product", "define-product", "define the product requirements", "what are we building and why", or run /define-product. Writes a multi-file PRD under docs/prds/<slug>/ with ID acceptance criteria. Ingests rich context first, shows the flow, drafts from supplied material, asks only blocking questions, records safe assumptions, and recommends the next step: plan-delivery-track for simple features, design-technical-solution for complex technical work, UX/content pass for UI-heavy work, or validation/research for research-heavy work. Idempotent: never clobbers an existing PRD without confirmation.
Use before delivery-track planning when product or design context has meaningful technical complexity: new modules, data/query changes, AI prompts/tools/triggers, observability, migrations/deploy surfaces, security boundaries, or multi-system integration. Can start from a PRD, existing design docs, technical notes, or session context when enough scope exists. Writes a high-level technical solution document for plan-delivery-track to consume. Ingests rich context first, shows the flow, asks only blocking questions, and records safe assumptions.
Use to decompose product or design context into a delivery tracker and lightweight story briefs. Accepts a PRD plus technical solution, a technical solution alone, or explicit backlog/design context when enough scope, outcomes, sequencing, and validation expectations exist. For complex technical work, require a technical solution or equivalent external design context before writing tracker stories. Produces docs/tracks/<track>/README.md plus docs/tracks/<track>/stories/<ID>.md briefs that cite PRD criteria or context-derived outcomes and technical solution sections or external context labels. Story briefs are not implementation-ready; implement-next creates the detailed technical story spec and implementation plan before code.