Create Feature Checklist

You are creating quality checklists for different aspects of feature development. Checklists serve as pre-implementation gates that ensure quality standards are met before proceeding.

Upstream source: github/spec-kit

Prerequisites

• A feature spec must exist at specs/[###-feature-name]/spec.md
• A feature plan may exist at specs/[###-feature-name]/plan.md

Checklist Types

You can create checklists for the following domains:

Domain	Filename	Purpose
Requirements	requirements.md	Spec quality and completeness (auto-created by /spec-kit:specify)
Security	security.md	Security review gates
Performance	performance.md	Performance validation criteria
UX	ux.md	User experience review
Testing	testing.md	Test coverage requirements
Accessibility	accessibility.md	Accessibility standards
Custom	[name].md	Any project-specific checklist

Workflow

Step 1: Identify Feature and Checklist Type

• If the user specifies a feature name/number, locate it in specs/
• If multiple features exist, list them and ask the user to choose
• Ask (or infer from user message) which checklist type to create

Step 2: Load Context

Read the available spec and plan artifacts to inform checklist items:

• specs/[###-feature]/spec.md (required)
• specs/[###-feature]/plan.md (if exists)
• .speckit/constitution.md (if exists — add principle-specific checks)

Step 3: Generate Checklist

Create specs/[###-feature]/checklists/[type].md:

Requirements Checklist (requirements.md):

# Specification Quality Checklist: [FEATURE NAME]

**Purpose**: Validate specification completeness before planning
**Created**: [TODAY]
**Feature**: ../spec.md

## Content Quality
- [ ] No implementation details (languages, frameworks, APIs)
- [ ] Focused on user value and business needs
- [ ] Written for non-technical stakeholders
- [ ] All mandatory sections completed

## Requirement Completeness
- [ ] No [NEEDS CLARIFICATION] markers remain
- [ ] Requirements are testable and unambiguous
- [ ] Success criteria are measurable and technology-agnostic
- [ ] All acceptance scenarios defined using Given/When/Then
- [ ] Edge cases are identified
- [ ] Assumptions documented

## Feature Readiness
- [ ] Each user story is independently testable
- [ ] All functional requirements have clear acceptance criteria
- [ ] Scope is clearly bounded

Security Checklist (security.md):

# Security Checklist: [FEATURE NAME]

**Purpose**: Validate security requirements before implementation
**Created**: [TODAY]
**Feature**: ../spec.md

## Authentication & Authorization
- [ ] Authentication requirements are defined (if applicable)
- [ ] Authorization model is specified (who can do what)
- [ ] Privilege escalation scenarios are considered

## Data Protection
- [ ] Sensitive data is identified and classified
- [ ] Data encryption requirements are defined (at rest / in transit)
- [ ] PII handling requirements are documented

## Input Validation
- [ ] All input sources are identified
- [ ] Validation rules are defined for each input
- [ ] Error messages don't leak sensitive information

## API Security (if applicable)
- [ ] API authentication mechanism is defined
- [ ] Rate limiting is specified
- [ ] CORS policy is appropriate

## Audit & Logging
- [ ] Security-relevant events are identified for logging
- [ ] Log sensitivity classification is done

Performance Checklist (performance.md):

# Performance Checklist: [FEATURE NAME]

**Purpose**: Define measurable performance targets before implementation
**Created**: [TODAY]
**Feature**: ../spec.md

## Response Time
- [ ] Target response time for primary user actions is defined in spec SC-###
- [ ] Acceptable degradation under load is specified
- [ ] Timeout values are defined

## Scalability
- [ ] Expected concurrent user count is specified
- [ ] Data volume assumptions are documented
- [ ] Horizontal/vertical scaling strategy is noted in plan

## Resource Usage
- [ ] Memory usage constraints are defined (if applicable)
- [ ] CPU usage bounds are noted (if applicable)
- [ ] Storage growth projections are estimated

## Caching
- [ ] Cacheable operations are identified
- [ ] Cache invalidation strategy is defined (if applicable)

Testing Checklist (testing.md):

# Testing Checklist: [FEATURE NAME]

**Purpose**: Ensure test coverage requirements are defined
**Created**: [TODAY]
**Feature**: ../spec.md

## Test Coverage Requirements
- [ ] Each user story has at least one acceptance test scenario
- [ ] Edge cases have corresponding test cases
- [ ] Negative scenarios (failure cases) are covered

## Test Types Required
- [ ] Unit tests: [list components requiring unit testing]
- [ ] Integration tests: [list integration points]
- [ ] Contract tests: [list external interfaces] (if applicable)
- [ ] End-to-end tests: [list critical user journeys] (if applicable)

## Test Independence
- [ ] Each user story's tests can run in isolation
- [ ] Tests do not have order dependencies
- [ ] Test data setup and teardown is handled

## Performance Testing (if applicable)
- [ ] Load test scenarios are defined (based on SC-### targets)

Custom Checklist: Adapt the appropriate template above and ask the user what specific items they want to track. Generate items based on:

• The feature's requirements and constraints
• The tech stack from the plan
• The project's constitution principles

Step 4: Output Summary

Checklist Created: specs/[###-feature-name]/checklists/[type].md

  Type: [checklist type]
  Items: [count]
  
  Categories:
    [Category 1]: [count] items
    [Category 2]: [count] items
    ...

  Usage:
    - Complete this checklist before running /spec-kit:implement
    - The implement skill will check if checklists are complete before proceeding
    - Mark items [x] as you complete or verify them

Important Rules

• Checklists are gates, not just documentation — they block implementation if incomplete
• All items must be checkboxes using - [ ] format
• Items should be verifiable: "Authentication requirements are defined" not "Consider authentication"
• Generate items specific to the feature, not generic boilerplate
• If a checklist item doesn't apply to the feature, note why in a comment rather than leaving it unchecked
• The requirements.md checklist is automatically created by /spec-kit:specify — don't recreate it unless the user explicitly wants to regenerate it