Commands Reference
All commands are available as slash commands in your AI coding agent after running specify init.
Core Workflow
These commands form the main Spec-Driven Development pipeline:
/speckit.constitution
Create or update project governing principles and development guidelines.
/speckit.constitution Code quality, testing standards, security, accessibility- Output:
.specify/memory/constitution.md - When to use: Once at project start, update as principles evolve
- Learning loop: After implementation cycles, it can analyze patterns and suggest new principles
/speckit.specify
Define what you want to build — requirements, user stories, and acceptance criteria.
/speckit.specify Build a photo album app with drag-and-drop organization- Output:
.specify/specs/NNN-feature-name/spec.md - When to use: For each new feature
- Creates: Feature branch, numbered directory, structured spec from template
- Maturity tracking: Specs start at
draftand evolve throughrefined → validated → implemented → evolved
/speckit.plan
Create a technical implementation plan with architecture and tech stack decisions.
/speckit.plan Use React with TypeScript, PostgreSQL, deploy to AWS- Output:
plan.md,data-model.md,research.md,contracts/ - When to use: After spec is written and clarified
- Reads:
spec.md, constitution, architecture spec
/speckit.tasks
Generate an actionable, ordered task breakdown from the implementation plan.
/speckit.tasks- Output:
tasks.md - When to use: After plan is created
- Features: Dependency ordering, parallel markers
[P], file paths, TDD structure, checkpoints
/speckit.implement
Execute all tasks to build the feature according to the plan.
/speckit.implement- When to use: After tasks are generated (and optionally analyzed)
- Reads: All spec artifacts (constitution, spec, plan, tasks)
- Behavior: Executes tasks in order, follows TDD, reports progress
Design & Infrastructure
/speckit.brand
Initialize or update the project's branding specification with design tokens.
/speckit.brand Modern SaaS with teal colors and clean typography- Output:
.specify/branding/branding.md+.specify/branding/tokens.json - When to use: Once at project start, before creating design specs
- Covers: Colors (light/dark themes), typography scale, spacing, shadows, borders, motion, iconography
/speckit.design
Create UI component specs, user flow specs, or screen layout specs for a feature.
/speckit.design Design the user dashboard with navigation, stats cards, and activity feed- Output:
.specify/specs/NNN-feature-name/design.md - When to use: After branding is defined, alongside or after
/speckit.specify - Reads: Branding spec for token consistency
- Validates: WCAG contrast ratios, accessibility requirements, token references
/speckit.infra
Create or update the infrastructure specification for development and production environments.
/speckit.infra Docker Compose for dev, Kubernetes with Helm for production- Output:
.specify/infra/infra.md - When to use: At project start or when infrastructure changes
- Scans: Existing Docker Compose, Helm charts, CI/CD, Makefiles, env templates
- Covers: Dev environment, prod deployment (5-phase), data layer, CI/CD, observability, DR
- Scaffolding: Can generate
docker-compose.yml,Makefile, Helm charts,.gitlab-ci.yml,deploy.sh
Consistency & Quality
/speckit.reconcile
Cross-artifact conflict detection and interactive resolution. Runs automatically after every spec-modifying command.
/speckit.reconcile- Triggers after:
/speckit.specify,/speckit.clarify,/speckit.constitution,/speckit.brand,/speckit.infra,/speckit.design - Reads: All existing specs, plans, tasks, constitution, branding, infrastructure
- Detection passes: Contradiction detection, constitution violations, terminology drift, scope overlap, dependency conflicts, branding inconsistency, infrastructure misalignment
- Interactive: Presents each conflict with options (keep new / keep existing / merge / defer)
- Log:
.specify/memory/reconciliation-log.md - Learn more: Auto-Reconciliation
/speckit.clarify
Interactive Q&A to fill specification gaps. Asks structured questions about underspecified areas.
/speckit.clarify- When to use: After
/speckit.specify, before/speckit.plan - Behavior: Sequential coverage-based questioning, records answers in spec
/speckit.analyze
Cross-artifact consistency and quality analysis across spec, plan, and tasks.
/speckit.analyze- When to use: After
/speckit.tasks, before/speckit.implement - Read-only: Never modifies files
- Checks: Coverage gaps, orphan tasks, terminology drift, constitution violations, ambiguity, design token consistency
- Scoring: 100-point rubric (completeness 30, consistency 25, testability 25, clarity 20)
- Rating: Excellent (90+), Good (80+), Fair (70+), Poor (<70)
/speckit.checklist
Generate custom quality checklists that validate requirements completeness and clarity.
/speckit.checklist- When to use: Anytime you want to validate spec quality
- Output: Markdown checklist ("unit tests for English")
/speckit.refine
Review and apply auto-generated refinement suggestions for specs.
/speckit.refine- When to use: After implementation, or after constitution updates
- Detects: Gaps (thin specs vs. complex implementation), staleness (code changed since spec), consistency issues
- Interactive: Presents suggestions, you approve/reject each one
- Updates: Spec maturity tracking, Project History Record
/speckit.levelup
Capture team conventions, patterns, and lessons learned as reusable directives.
/speckit.levelup We always use kebab-case for file names- Output:
.specify/memory/directives/{slug}.md+ updatesindex.md - When to use: When a team pattern emerges that should be consistent
- Types: Convention, Pattern, Lesson, Guideline
- Alignment: Checks against constitution, suggests amendments if needed