Spec Kit Checklist

Generate domain-specific checklists that evaluate requirement quality in Spec Kit artifacts.

Invocation Notice

• Inform the user when this skill is being invoked by name: spec-kit-checklist.

When to Use

• spec.md exists and you need a checklist to review requirement quality before implementation.
• You want a focused lens (for example UX, API, security, performance, accessibility) over requirement quality.
• You need to surface ambiguity, missing coverage, or weak acceptance criteria in writing.

When Not to Use

• You are writing runtime tests, QA scripts, or implementation verification steps.
• spec.md does not exist yet (spec-kit-specify first).
• High-impact ambiguity must be resolved in-spec before checklist generation (spec-kit-clarify).
• You are generating executable tasks (spec-kit-tasks) or implementing tasks (spec-kit-implement).

Router Fit

• Primary route from spec-kit when the intent is requirement-quality checklist generation.
• Can be run as a standalone quality pass after spec-kit-specify/spec-kit-clarify and before or during implementation.
• Output checklists feed the optional checklist gate in spec-kit-implement.

Preconditions

• Run from repository root (or a subdirectory inside it).
• Active feature context resolves to one specs/<feature>/ directory.
• spec.md exists for that feature.

Workflow

1. Resolve feature paths and enforce the checklist prerequisite gate:

• Run scripts/check-prerequisites.sh --paths-only --json exactly once.
• Parse and retain REPO_ROOT, FEATURE_DIR, and FEATURE_SPEC.
• If FEATURE_SPEC (spec.md) is missing, stop and route to spec-kit-specify.

1. Load checklist context:

• Required: spec.md.
• Optional when present: plan.md, tasks.md.
• Extract only requirement-relevant content: requirements, acceptance criteria, edge/error cases, non-functional constraints, assumptions/dependencies.

1. Clarify checklist scope only when needed:

• Ask up to 3 concise, high-impact questions if scope/risk/audience is unclear.
• Skip questions already answered in user input or artifacts.
• If ambiguity still blocks item quality, ask up to 2 targeted follow-ups (max 5 total).

1. Choose checklist file target:

• Ensure FEATURE_DIR/checklists/ exists.
• Derive a short domain slug from intent (for example ux, api, security, performance).
• Create a new file per run: prefer <slug>.md; if it exists, create <slug>-2.md, <slug>-3.md, etc.
• Never overwrite existing checklist files.

1. Generate requirement-quality checklist items:

• Treat each item as a "unit test for requirement writing," not implementation behavior.
• Group items under quality categories as needed:
• Requirement Completeness
• Requirement Clarity
• Requirement Consistency
• Acceptance Criteria Quality / Measurability
• Scenario and Edge-Case Coverage
• Non-Functional Requirements
• Dependencies and Assumptions
• Ambiguities and Conflicts
• Use CHK### IDs starting at CHK001 and increment sequentially.
• Keep items in question form and focused on what is documented or missing.

1. Apply strict item-quality rules:

• Prefer patterns such as:
• Are <requirements> defined/specified for <scenario>?
• Is <term> quantified with measurable criteria?
• Are requirements consistent between <section A> and <section B>?
• Do not generate implementation checks (for example click/render/load/execute behavior checks).
• Do not use runtime-verification framing (Verify, Test, Confirm) for system behavior.
• Include traceability on most items (target: >=80%) using markers like [Spec §...], [Gap], [Ambiguity], [Conflict], [Assumption].

1. Write output using template structure:

• Preferred template: {REPO_ROOT}/templates/checklist-template.md.
• Fallback template: assets/checklist-template.md.
• Preserve heading order and emit checklist rows in this format:
• - [ ] CHK### <question> [markers]

1. Validate before final report:

• No implementation/runtime verification items.
• IDs are unique and sequential.
• Items are requirement-quality questions.
• Traceability markers meet target coverage.

1. Report completion:

• Absolute checklist path.
• Item count.
• Selected focus areas, depth/audience assumptions, and any explicit must-have user constraints incorporated.
• Reminder that each run creates a new checklist file.

Output

• New checklist file in specs/<feature>/checklists/.
• Requirement-quality checklist items with sequential CHK### IDs.
• Summary of scope assumptions and checklist focus.

Key Rules

• Evaluate the quality of requirements writing, not whether implementation works.
• Keep items objective, reviewable, and traceable to artifacts.
• Prefer concise, high-signal checklists over exhaustive low-value lists.

Common Mistakes

• Writing QA/runtime checks ("verify the API returns 200") instead of requirement-quality checks ("requirement specifies expected response codes").
• Producing vague items with no traceability marker.
• Overfitting to implementation details that do not belong in requirements artifacts.
• Overwriting an existing checklist instead of creating a new file for the run.

References

• scripts/check-prerequisites.sh
• assets/checklist-template.md
• https://github.com/github/spec-kit/blob/9111699cd27879e3e6301651a03e502ecb6dd65d/templates/commands/checklist.md