Kickoff
Generates requirements/UX spec/architecture/data model/issues/test plan from a PRD. Runs 6 subagents in sequence.From its SKILL.md
npx -y skills add pillip/claude-dev-kit --skill kickoffAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 11 stars11 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
11.5 KB, as published. Nobody here has run it
Kit Preamble — kickoff
Kit Script Root
Kit root: ${CLAUDE_PLUGIN_ROOT}
- Absolute path above → plugin install (substituted at load time; no project
scripts/dir): prefix every kit script command with it, e.g.bash <kit-root>/scripts/checkpoint.sh …. Absolute paths also work from worktrees. - Literal
${…}placeholder above → standalone layout: run commands as written.
Project Context Detection
Run these checks silently at the start. Use results to adapt behavior:
[ -f issues.md ]— if true, this project uses the sprint system. Respect issue numbering and STATUS.md.[ -f docs/sprint_state.md ]— if true and Status showsrunning, a sprint is active. Be aware of parallel work in worktrees.[ -f docs/prd_digest.md ]— if true, read it for quick project context before starting.
Kit Rules
- Verify
gh auth statusbefore any GitHub operation.
Checkpoint Verification Pattern
Every phase has a checkpoint. Run the verification command and check the exit code.
- Exit non-zero (blocking gate): STOP immediately, report failure, do NOT proceed.
- Exit 0 with an
ADVISORY:line (advisory gate): report the gap, self-correct, continue. Standard prefix:
bash scripts/checkpoint.sh
Append --skill <name> --phase <phase> --issue <ID> for the specific check.
checkpoint.sh resolves the main repo root internally, so the command stays
a single prefix-matchable form (safe to allowlist as Bash(bash scripts/checkpoint.sh *)).
Worktree Setup Pattern
Pipeline skills operate in git worktrees to isolate changes from main.
- Create + freeze:
WT="$(bash scripts/wt_setup.sh <branch>)"— creates the worktree viascripts/worktree.sh createand writes.claude-kit/freeze-dir.txtinside it in a single step. - Resolve main root:
bash scripts/worktree.sh root - Remove safely:
bash scripts/wt_cleanup.sh <branch>— cd's to main root inside a subshell, then removes the worktree (never leaves CWD dangling). All file operations happen inside$WT/. Shared files live on main only.
Registry Update Pattern
Shared files (issues.md, STATUS.md, CHANGELOG.md) are managed on main only.
Always use registry_edit.sh for concurrent-safe writes — it resolves the
main repo root internally and delegates to flock_edit.sh:
bash scripts/registry_edit.sh issues.md -- bash -c '<update command>'
Never commit these files to feature branches.
Algorithm
Phase 1 — Setup
- Ensure
docs/directory exists. - Read PRD (
$ARGUMENTSorPRD.md). If not found, stop immediately and report. - Read existing project files if any (README, pyproject.toml, etc.) to understand tech stack context.
Phase 1.5 — PRD Digest (MUST run before Phase 2)
Regardless of PRD length, always generate a summary with the following structure and save it to docs/prd_digest.md:
- Goals (3 lines or fewer)
- Target User (1 line)
- Must-have Features (numbered list, 1 line each)
- Key NFRs (numbered list, 1 line each)
- Scope Boundaries (In/Out, 3 lines or fewer each)
When passing context to subsequent subagents: include both the original PRD and docs/prd_digest.md.
CHECKPOINT — MANDATORY — NEVER SKIP Verify
docs/prd_digest.mdexists and contains all required sections (Goals, Target User, Must-have Features, Key NFRs, Scope Boundaries). If the file is missing or any section is empty: STOP and regenerate before proceeding.
Phase 2 — Run Subagents (dependency-aware, parallel where possible)
Step 1: requirement-analyst → docs/requirements.md
- Context to pass: Full PRD content +
docs/prd_digest.md - Agent produces: Goals, prioritized user stories with AC, FRs, NFRs with measurable targets, scope, assumptions, risks
- Verify output exists before proceeding
CHECKPOINT — MANDATORY — NEVER SKIP Verify
docs/requirements.mdexists and contains Goals, User Stories, and NFRs sections. If missing or incomplete: STOP and retry the requirement-analyst subagent before proceeding.
Step 2 & 3 — MUST invoke both subagents simultaneously via two parallel Task tool calls in a single message: Both agents depend on requirements but NOT on each other. Run them in parallel to save ~5-8 minutes.
ux-designer → docs/ux_spec.md
- Context to pass: PRD +
docs/prd_digest.md+docs/requirements.md - Agent produces: IA, key flows with error paths, screen list with 5 states each, copy guidelines, accessibility notes
architect → docs/architecture.md
- Context to pass: PRD +
docs/prd_digest.md+docs/requirements.md - Note: ux_spec is NOT available yet (running in parallel). Architect focuses on tech stack and module design from requirements. UX-driven API refinements happen during implementation.
- Agent produces: Tech stack, modules, data model, API design, security, deployment, tradeoffs table
After both Task calls return, verify both outputs exist before proceeding.
CHECKPOINT — MANDATORY — NEVER SKIP Verify both
docs/ux_spec.mdanddocs/architecture.mdexist.
docs/ux_spec.mdmust contain Key Flows and screen definitions.docs/architecture.mdmust contain tech stack and module design. If either file is missing or empty: STOP and retry the failed subagent before proceeding.
Step 4: data-modeler → docs/data_model.md
- Context to pass: PRD +
docs/prd_digest.md+docs/requirements.md+docs/ux_spec.md+docs/architecture.md - Agent produces: Access patterns, detailed schema (tables, columns, types, constraints), indexes with justification, migration strategy, seed data, query patterns, scaling notes
- Verify output exists before proceeding
CHECKPOINT — MANDATORY — NEVER SKIP Verify
docs/data_model.mdexists and contains schema definitions with tables, columns, and types. If missing or incomplete: STOP and retry the data-modeler subagent before proceeding.
Step 5 & 6 — MUST invoke both subagents simultaneously via two parallel Task tool calls in a single message (no dependency between them):
planner → issues.md
- Context to pass: PRD +
docs/prd_digest.md+docs/requirements.md+docs/ux_spec.md+docs/architecture.md+docs/data_model.md+ recalled review lessons (native memory; passed in your prompt when you run as a subagent) - Agent produces: Issues sized 0.5d–1.5d with AC, tests, dependencies, implementation notes
- Instruct the planner to set the
UIfield on each issue:trueif the issue involves UI/frontend work (screens, components, styling, user-facing interactions),falseotherwise.
qa-designer → docs/test_plan.md
- Context to pass: PRD +
docs/prd_digest.md+docs/requirements.md+docs/ux_spec.md+docs/architecture.md+docs/data_model.md - Agent produces: Risk matrix, critical flow test cases, edge cases, fixtures, automation candidates, smoke checklist
After both Task calls return, verify both outputs exist before proceeding to Phase 3.
CHECKPOINT — MANDATORY — NEVER SKIP Verify both
issues.mdanddocs/test_plan.mdexist.
issues.mdmust contain at least one### ISSUE-block with AC and metadata fields.docs/test_plan.mdmust contain Strategy and Critical Flows sections. If either file is missing or empty: STOP and retry the failed subagent before proceeding.
Phase 3 — Supporting Documents
- Create/update
docs/README.md:- Project name and description (from PRD)
- Prerequisites (from architecture tech stack)
- Setup instructions (install, configure, run)
- Test instructions
- Create/update
STATUS.md:- Current milestone (from PRD goals)
- Issue summary (total, by priority, by track)
- Key risks (from requirements)
- Next issues to implement (top 3 P0 issues)
Phase 4 — Verification
- Run
scripts/validate_issues.py issues.mdto validate issue quality:- If violations are found, re-invoke the planner subagent once with the violation list and ask it to fix the issues.
- If violations remain after the retry, log them in
STATUS.mdunder## Warningsand proceed. 6.5) Cross-document validation — verify consistency between subagent outputs: - data_model ↔ architecture: Entity names in
docs/data_model.mdshould match the data model overview indocs/architecture.md. Flag mismatches. - issues ↔ requirements: Every FR/NFR referenced in
issues.md(PRD-Ref field) should exist indocs/requirements.md. Flag dangling references. - test_plan ↔ requirements: Critical flows in
docs/test_plan.mdshould map to high-priority requirements. Flag uncovered Must-have FRs. - ux_spec ↔ requirements: Every user story in
docs/requirements.mdshould have at least one screen or flow indocs/ux_spec.md. Flag orphans. - If mismatches are found: log them in
STATUS.mdunder## Cross-Validation Warningsand proceed. These are informational — they do NOT block the pipeline.
- Verify all required outputs exist:
docs/requirements.mddocs/ux_spec.mddocs/architecture.mddocs/data_model.mddocs/test_plan.mdissues.mdSTATUS.md
- Report summary to the user:
- Number of FRs/NFRs identified
- Number of screens in UX spec
- Architecture style chosen
- Number of issues created
- Suggest next step:
/uiux(web UI project),/mobile-uiux(mobile app project), or/implement ISSUE-001
Subagent Invocation Pattern
When invoking each subagent via the Task tool:
- Include the agent name in the prompt (e.g., "You are the requirement-analyst agent")
- Pass the full content of input documents — do NOT just pass file paths
- Specify the exact output file path
- Include: "Write your output to
docs/<file>.md. Follow your agent guidelines precisely."
Error Handling
- If a subagent fails (Task tool returns error):
- Retry the failed subagent once with the same context.
- If it fails again, skip with a warning message and continue with remaining subagents.
- Log the skipped subagent in
STATUS.mdunder a## Warningssection.
- If the PRD file is not found: stop immediately and report the missing path.
- If
docs/cannot be created: stop immediately and report the filesystem error. - If a subagent produces empty or malformed output: treat as failure, retry once.
Rollback
- Kickoff is additive (writes new files); no destructive rollback is needed.
- If partially completed, re-running
/kickoffoverwrites all outputs — safe to retry. - If a subagent was skipped, re-run
/kickoffafter fixing the root cause to regenerate the missing document.
Guidelines
- The dependency order is critical: requirements → (UX + architecture in parallel) → data model → (planner + QA in parallel).
- ux-designer + architect MUST be invoked in parallel: Both subagents only need requirements and have no dependency on each other.
- planner + QA MUST be invoked in parallel: Both subagents have no dependency on each other, so they must be executed as two Task tool calls simultaneously in a single message.
- Each subagent should receive ALL prior outputs as context for maximum coherence.
- Do NOT modify subagent outputs after they are written — each agent owns its document.
- PRD Digest is always generated in Phase 1.5 (no length condition). Individual subagents should not create their own summaries.