spec-kit-checklist（规格套件清单）

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