spec-kit/templates/commands/checklist.md

---
description: Generate a custom checklist for the current feature based on user requirements.
scripts:
  sh: scripts/bash/check-prerequisites.sh --json
  ps: scripts/powershell/check-prerequisites.ps1 -Json
---

## User Input

```text
$ARGUMENTS
```

You **MUST** consider the user input before proceeding (if not empty).

## Execution Steps

1. **Setup**: Run `{SCRIPT}` from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS list.
   - All file paths must be absolute.

2. **Clarify intent (dynamic)**: Derive THREE contextual clarifying questions (no pre-baked catalog). They MUST:
   - Be generated from the user's phrasing + extracted signals from spec/plan/tasks
   - Only ask about information that materially changes checklist content
   - Be skipped individually if already unambiguous in `$ARGUMENTS`
   - Prefer precision over breadth

   Generation algorithm:
   1. Extract signals: feature domain keywords (e.g., auth, latency, UX, API), risk indicators ("critical", "must", "compliance"), stakeholder hints ("QA", "review", "security team"), and explicit deliverables ("a11y", "rollback", "contracts").
   2. Cluster signals into candidate focus areas (max 4) ranked by relevance.
   3. Identify probable audience & timing (author, reviewer, QA, release) if not explicit.
   4. Detect missing dimensions: scope breadth, depth/rigor, risk emphasis, exclusion boundaries, measurable acceptance criteria.
   5. Formulate up to three questions chosen from these archetypes:
      - Scope refinement (e.g., "Should this include integration touchpoints with X and Y or stay limited to local module correctness?")
      - Risk prioritization (e.g., "Which of these potential risk areas should receive mandatory gating checks?")
      - Depth calibration (e.g., "Is this a lightweight pre-commit sanity list or a formal release gate?")
      - Audience framing (e.g., "Will this be used by the author only or peers during PR review?")
      - Boundary exclusion (e.g., "Should we explicitly exclude performance tuning items this round?")

   Question formatting rules:
   - If presenting options, generate a compact table with columns: Option | Candidate | Why It Matters
   - Limit to A–E options maximum; omit table if a free-form answer is clearer
   - Never ask the user to restate what they already said
   - Avoid speculative categories (no hallucination). If uncertain, ask explicitly: "Confirm whether X belongs in scope." 

   Defaults when interaction impossible:
   - Depth: Standard
   - Audience: Reviewer (PR) if code-related; Author otherwise
   - Focus: Top 2 relevance clusters

   Output the three questions (or fewer if not needed) and wait for answers before continuing. Clearly label each as Q1/Q2/Q3.

3. **Understand user request**: Combine `$ARGUMENTS` + clarifying answers:
   - Derive checklist theme (e.g., security, review, deploy, ux)
   - Consolidate explicit must-have items mentioned by user
   - Map focus selections to category scaffolding
   - Infer any missing context from spec/plan/tasks (do NOT hallucinate)

4. **Load feature context**: Read from FEATURE_DIR:
   - spec.md: Feature requirements and scope
   - plan.md (if exists): Technical details, dependencies
   - tasks.md (if exists): Implementation tasks
   - Use context to enrich or validate checklist items (omit irrelevant categories)

5. **Generate checklist**:
   - Create `FEATURE_DIR/checklists/` directory if it doesn't exist
   - Generate unique checklist filename:
     * Use short, descriptive name based on checklist type
     * Format: `[type].md` (e.g., `ux.md`, `test.md`, `security.md`, `deploy.md`)
     * If file exists, append counter: `[type]-2.md`, `[type]-3.md`, etc.
     * Examples: `ux.md`, `test.md`, `security.md`, `deploy.md`, `review-2.md`
   - Use format: `[ ] CHK001 Item description here`
   - Number items sequentially starting from CHK001
   - Group items by category/section if applicable
   - Include brief explanations or links where helpful
   - Each `/checklist` run creates a NEW file (never overwrites existing checklists)

6. **Checklist structure**:
   ```markdown
   # [Checklist Type] Checklist: [Feature Name]
   
   **Purpose**: [Brief description of what this checklist covers]
   **Created**: [Date]
   
   ## [Category 1]
   - [ ] CHK001 First item
   - [ ] CHK002 Second item
   
   ## [Category 2]
   - [ ] CHK003 Third item
   ```

7. **Report**: Output full path to created checklist, item count, and remind user that each run creates a new file. Summarize:
   - Focus areas selected
   - Depth level
   - Actor/timing
   - Any explicit user-specified must-have items incorporated

**Important**: Each `/checklist` command invocation creates a NEW checklist file using short, descriptive names. This allows:
- Multiple checklists of different types (e.g., `ux.md`, `test.md`, `security.md`)
- Simple, memorable filenames that indicate checklist purpose
- Counter-based uniqueness for duplicate types (e.g., `review-2.md`)
- Easy identification and navigation in the checklists/ folder

To avoid clutter, use descriptive types and clean up obsolete checklists when done.

## Example Checklist Types

**Code Review:** `review.md`
- Code quality checks
- Documentation requirements
- Test coverage verification
- Security considerations

**Pre-Deployment:** `deploy.md`
- Build verification
- Test execution
- Configuration validation
- Rollback plan

**Accessibility:** `ux.md` or `a11y.md`
- WCAG compliance
- Keyboard navigation
- Screen reader compatibility
- Color contrast

**Security:** `security.md`
- Input validation
- Authentication/authorization
- Data encryption
- Dependency vulnerabilities

Generate checklist items that are specific, actionable, and relevant to the feature context.