Skip to main content
The /speckit.constitution command creates and updates your project’s constitution - a living document that defines core principles, constraints, and governance rules.

​
Purpose

The constitution serves as the single source of truth for project-wide decisions:
  • Non-negotiable technical principles
  • Complexity constraints and limitations
  • Quality standards and testing requirements
  • Architectural patterns and anti-patterns
  • Governance and amendment procedures
The constitution is referenced by all other commands. Plan validation, task generation, and implementation all check against constitutional principles.

​
Usage

# Create initial constitution interactively
/speckit.constitution

# Update with specific principles
/speckit.constitution Add principle: All APIs must be versioned

# Update governance section
/speckit.constitution Update ratification date to 2024-03-15

​
How It Works

1

Load Existing Constitution

Reads .specify/memory/constitution.md and identifies all placeholder tokens like [PROJECT_NAME], [PRINCIPLE_1_NAME]
2

Collect Values

Gathers values from:
  • User input (your command arguments)
  • Repository context (README, existing docs)
  • Previous constitution versions
  • Reasonable defaults for governance dates
3

Fill Template

Replaces all placeholders with concrete values:
  • Project name and description
  • Principle definitions with rationales
  • Governance procedures
  • Version information
4

Propagate Changes

Updates dependent templates:
  • plan-template.md (Constitution Check section)
  • spec-template.md (alignment requirements)
  • tasks-template.md (principle-driven task types)
  • Agent command files (if using specific AI assistants)
5

Generate Report

Creates a Sync Impact Report showing:
  • Version change (old → new)
  • Modified principles
  • Templates requiring updates
  • Follow-up TODOs

​
Constitution Structure

​
Metadata Section

# Project Constitution: [PROJECT_NAME]

**Version**: [CONSTITUTION_VERSION]  
**Ratified**: [RATIFICATION_DATE]  
**Last Amended**: [LAST_AMENDED_DATE]

​
Core Principles

Each principle includes:
  • Name: Short, memorable identifier
  • Rule: Non-negotiable MUST/SHOULD statements
  • Rationale: Why this principle exists
### Principle 1: Simplicity First

**Rule**: The project MUST favor the simplest solution that meets requirements.

**Rationale**: Complexity is the enemy of maintainability. We optimize for:
- Code readability over cleverness
- Explicit behavior over implicit magic
- Boring, proven patterns over novel approaches

**Application**:
- Maximum of 3 core projects/services
- No repository pattern unless data access complexity justifies it
- Avoid premature abstraction

​
Governance Section

## Governance

### Amendment Procedure
1. Propose change via pull request
2. Justify with concrete use case
3. Require approval from [ROLE/TEAM]
4. Update version according to semantic versioning
5. Propagate to all dependent templates

### Versioning Policy
- **MAJOR**: Backward incompatible principle changes
- **MINOR**: New principles added
- **PATCH**: Clarifications and wording improvements

### Compliance Review
- Quarterly review of all features for constitutional alignment
- Violations must be documented and justified
- Technical debt items created for gradual remediation

​
Versioning

The constitution uses semantic versioning:
MAJOR.MINOR.PATCH
  • MAJOR: Backward incompatible changes (principle removals, redefinitions)
  • MINOR: New principles or expanded guidance
  • PATCH: Clarifications, typo fixes, wording improvements

​
Version Examples

  • 1.0.0 → 2.0.0: Removed “Microservices First” principle
  • 1.0.0 → 1.1.0: Added “API Versioning” principle
  • 1.1.0 → 1.1.1: Clarified wording in Principle 2

​
Consistency Propagation

When the constitution changes, the command updates:

​
Templates

  • plan-template.md: Updates Constitution Check gates
  • spec-template.md: Aligns requirement sections
  • tasks-template.md: Updates task categorization
  • commands/*.md: Removes agent-specific references

​
Documentation

  • README.md: Updates principle references
  • docs/quickstart.md: Reflects new constraints
  • Agent context files (if applicable)

​
Validation

Before finalizing, the command validates:
1

No Unexplained Placeholders

All [BRACKETED_TOKENS] must be replaced (or explicitly justified)
2

Version Matches Report

Version number in document matches Sync Impact Report
3

Dates in ISO Format

All dates follow YYYY-MM-DD format
4

Declarative Principles

Uses MUST/SHOULD/MAY keywords (not vague “should consider”)

​
Real-World Example

/speckit.constitution

​
Common Principles

​
Technical Constraints

  • Complexity Limits: “Maximum 3 microservices”
  • Technology Stack: “Python 3.11+ only, no version mixing”
  • Performance: “API responses < 200ms p95”
  • Dependencies: “Only well-maintained libraries (updated in last 6 months)“

​
Quality Standards

  • Testing: “80% code coverage minimum”
  • Documentation: “All public APIs documented with examples”
  • Code Review: “No direct commits to main, all changes via PR”
  • Security: “OWASP Top 10 compliance required”

​
Architectural Patterns

  • Separation of Concerns: “Controllers → Services → Repositories”
  • Error Handling: “Centralized error handler, no silent failures”
  • Configuration: “Environment-based config, no hardcoded values”
  • Observability: “Structured logging, metrics, and tracing required”

​
Handoffs

After updating the constitution:

Build Specification

Create a feature spec that aligns with updated principles

Technical Plan

Plan will validate against the new constitution

​
Best Practices

​
Keep Principles Testable

Avoid vague principles like “Code should be clean.” Instead, use measurable criteria: “Functions must be < 50 lines, cyclomatic complexity < 10.”

​
Document Rationale

Every principle should explain why it exists:
  • What problem does it solve?
  • What pain does it prevent?
  • What trade-offs does it accept?

​
Version Thoughtfully

Only increment MAJOR version when absolutely necessary:
  • Removing a principle is MAJOR
  • Relaxing a constraint is MINOR
  • Adding clarification is PATCH

​
Review Regularly

Schedule periodic reviews:
  • Quarterly: Check if principles still serve the project
  • After major features: Validate no violations occurred
  • When pain points emerge: Consider if constitution needs updating

​
File Location

.specify/
└── memory/
    └── constitution.md    # Your project constitution

​
Next Steps

Specify

Create feature specifications that align with your constitution

Build docs developers (and LLMs) love

Get started for freeTalk to us