Command Reference

Complete guide to all Spec Kit slash commands.

📖 Table of Contents

• Command Naming Convention
• Core Commands
  • /speckit.constitution
  • /speckit.specify
  • /speckit.clarify
  • /speckit.checklist
  • /speckit.plan
  • /speckit.tasks
  • /speckit.analyze
  • /speckit.implement
• Workflow Comparison
• Command Tips
• Advanced Usage
• What's Next?

Command Naming Convention

All commands use the speckit. prefix to prevent conflicts:

• Type full name: /speckit.specify
• Or just keyword: /specify (also works!)
• Prevents conflicts with other editor slash commands

Core Commands

/speckit.constitution

Purpose: Create or update project constitution (non-negotiable principles)

When to use: First step - establish guardrails

Example:

/speckit.constitution

Static website with minimal dependencies,
optimized for mobile and desktop (responsive),
with accessibility standards (WCAG AA).

What it does:

• Creates .speckit/memory/constitution.md
• Updates dependent templates
• Embeds constitutional checks throughout workflow

Pro tip: Share constitutions across teams for consistency

/speckit.specify

Purpose: Define requirements (WHAT and WHY)

When to use: After constitution - describe what you want

Example:

/speckit.specify

I am building a modern podcast website that should:
- Look sleek and professional
- Have a landing page with one featured episode
- Include episodes page, about page, and FAQ page
- Display 20 mock episodes
- Be mobile responsive

What it creates:

• spec.md with functional requirements
• User stories and acceptance criteria
• Acceptance checklist

Focus on: User needs, requirements, edge cases Avoid: Technology choices, implementation details

/speckit.clarify ✨

Purpose: Interactive Q&A to fix under-specification

When to use: After specify - eliminate assumptions

Example:

/speckit.clarify

AI: What episode metadata should be displayed?
A) Basic (title, date)
B) Standard (title, date, duration, description)
C) Extended (all fields + host, guests, tags)

You: C

What it does:

• Asks up to 5 clarification questions
• Provides multiple choice options
• Auto-updates spec with answers
• Logs session with timestamp

Why use it: Catches blind spots you didn't question

Pro tip: Just type the letter (A/B/C) - super fast!

/speckit.checklist ✨ NEW!

Purpose: Generate domain-specific quality checklists ("unit tests for English")

When to use: After specify/clarify - validate completeness

Syntax: /speckit.checklist <domain>

Examples:

/speckit.checklist UX
/speckit.checklist security
/speckit.checklist accessibility
/speckit.checklist performance

What it generates:

## Requirement Clarity
☐ Visual hierarchy defined for all page types
☐ Loading states defined for page transitions
☐ Error handling specified

## Requirement Consistency
☐ Navigation patterns consistent
☐ Layout approach aligned

## Testability
☐ Metrics include measurement conditions

How to use:

1. Generate checklist: /speckit.checklist UX
2. Review items
3. Cross-check: "Cross-check the UX checklist with spec.md"
4. AI updates spec to fill gaps

Domains:

• UX: Visual hierarchy, loading states, error handling, responsive behaviors
• Security: Authentication, authorization, data validation, encryption
• Accessibility: WCAG compliance, keyboard navigation, screen readers
• Performance: Load times, bundle sizes, Core Web Vitals

Why use it: Finds requirements you didn't know you were missing

/speckit.plan

Purpose: Technical planning (HOW to build it)

When to use: After spec validation

Example:

/speckit.plan

Use Next.js with static site configuration.
No databases needed - use mock data.
Make sure the site is responsive and mobile-ready.

What it creates:

• plan.md with technical details
• Framework and language choices
• Architecture decisions
• Dependencies
• Data models
• Testing strategy (optional)

Must respect: Constitution requirements

/speckit.tasks

Purpose: Break down into actionable tasks

When to use: After plan is complete

Example:

/speckit.tasks

Break this down into manageable tasks.

What it creates (NEW format):

## Phase 1: Setup & Shared Infrastructure
- Project scaffolding
- Base configuration

## Phase 2: Foundational Prerequisites
- Core dependencies
- Data structures

## Phase 3: MVP Implementation
- User Story 1: [Core feature]
  - Task breakdown

## Phase 4+: Iterations & Improvements
- User Story 2: [Enhancements]

Key improvements:

• ✨ MVP-first approach
• ✨ Phase-based structure
• ✨ User story organization
• ✨ Tests optional (no longer forced!)

To include tests: Explicitly state in plan

/speckit.analyze ⚠️

Purpose: Validate spec, plan, and tasks against constitution

When to use: BEFORE implement - catches inconsistencies

Example:

/speckit.analyze

What it does:

• Analyzes 3 core artifacts (spec, plan, tasks)
• Validates against constitution
• Finds discrepancies by severity:
  • Critical: Constitutional violations
  • Medium: Structural mismatches
  • Low: Minor inconsistencies
• Provides fix recommendations

Example output:

Severity: CRITICAL
Issue: Next.js violates "static HTML/CSS only" constitution
Recommendation: Either justify violation or return to vanilla approach

Severity: MEDIUM
Issue: Plan uses assets/ but tasks use app/ Next.js structure
Recommendation: Update plan to reflect actual structure

Why critical: Spots issues BEFORE coding starts

Best practice: ALWAYS run before /speckit.implement

/speckit.implement

Purpose: Execute implementation

When to use: After analysis passes - build it!

Example:

/speckit.implement

What it does:

• Checks prerequisites (ensures artifacts exist)
• Reads tasks and validates readiness
• Executes tasks sequentially by phase
• Updates task status as it progresses
• Creates all necessary files
• Runs tests (if specified)

Auto-approved scripts (VS Code + Copilot):

• No permission prompts!
• Faster iteration
• Scripts automatically approved

Pro tip: Use Claude* Sonnet 4 or GPT*-4 for best results

Workflow Comparison

Minimum (Quick Prototypes)

1. /speckit.constitution
2. /speckit.specify
3. /speckit.plan
4. /speckit.tasks
5. /speckit.implement

Recommended (Quality Projects)

1. /speckit.constitution
2. /speckit.specify
3. /speckit.clarify          ← Eliminates assumptions
4. /speckit.checklist UX     ← Validates completeness
5. /speckit.plan
6. /speckit.tasks
7. /speckit.analyze          ← Catches inconsistencies
8. /speckit.implement

Comprehensive (Production)

1. /speckit.constitution
2. /speckit.specify
3. /speckit.clarify
4. /speckit.checklist UX
5. /speckit.checklist security
6. /speckit.checklist accessibility
7. Cross-check all checklists with spec
8. /speckit.plan
9. /speckit.tasks
10. /speckit.analyze
11. /speckit.implement

Command Tips

Constitution

✅ DO: Encode critical, non-negotiable requirements ✅ DO: Share across teams for consistency ✅ DO: Include testing standards, accessibility, security ❌ DON'T: Put implementation details here

Specify

✅ DO: Be specific and detailed ✅ DO: Include edge cases and acceptance criteria ✅ DO: Focus on user needs and motivation ❌ DON'T: Mention technology or frameworks ❌ DON'T: Include implementation details

Clarify

✅ DO: Answer all questions thoughtfully ✅ DO: Choose specific options (not vague ones) ✅ DO: Run after initial spec ❌ DON'T: Skip this step (catches blind spots!)

Checklist

✅ DO: Generate multiple domain checklists (UX, security, accessibility) ✅ DO: Cross-check with spec after generating ✅ DO: Let AI update spec to fill gaps ❌ DON'T: Skip cross-checking (defeats the purpose!)

Plan

✅ DO: Reference constitution requirements ✅ DO: Specify all technical choices ✅ DO: State if tests are NOT needed ❌ DON'T: Contradict constitution

Tasks

✅ DO: Review generated tasks ✅ DO: Regenerate if spec/plan changes ❌ DON'T: Edit tasks manually (regenerate instead)

Analyze

✅ DO: ALWAYS run before implement ✅ DO: Address critical issues before proceeding ✅ DO: Update spec/plan/tasks based on findings ❌ DON'T: Skip this step (catches major issues!)

Implement

✅ DO: Ensure all prior steps completed ✅ DO: Review code as it's generated ✅ DO: Commit frequently ❌ DON'T: Run without analyzing first

Advanced Usage

For Existing Projects

Add these to your commands for better results:

/speckit.constitution

Use existing architecture in [describe folder structure].
Do not introduce new frameworks.
Follow patterns in [specific files/folders].

/speckit.specify

Add feature to existing project.
Must integrate with existing [describe components].
DO NOT modify [list files that shouldn't change].

Encoding Learnings

After implementation:

Based on the conversation, encode the learnings
and experience pieces (not technical details)
into spec.md for the current feature.

Then:
Transform the learnings into relevant functional requirements.

Unwinding Mistakes

If AI goes off-rails:

1. Update spec with correct requirements
2. Commit spec changes
3. Discard code changes in git client
4. Re-implement from updated spec

What's Next?

• New Project Guide - Step-by-step for new projects
• Existing Project Guide - Adding features to existing code
• Complete Guide - In-depth documentation

Master these commands and transform your development workflow! 🚀

Trademark Notice