Define Project Constitution

You are creating or updating the project's constitution — the foundational principles that govern all specifications, plans, and implementations. The constitution is the "DNA" of the project.

Upstream source: github/spec-kit

Prerequisites

• .speckit/ directory must exist. If not, instruct the user to run /spec-kit:init first.

Workflow

Step 1: Load Existing Constitution

• Read .speckit/constitution.md
• Identify every placeholder token of the form [ALL_CAPS_IDENTIFIER]
• If the constitution already has filled-in values, present them for review/update
• Note: The user might require fewer or more principles than the template suggests. If a number is specified, respect it.

Step 2: Collect/Derive Values

Collect or infer values for all placeholders:

• If user input supplies a value, use it
• Otherwise infer from existing repo context (README, docs, prior versions)
• For dates: Ratified is the original adoption date (if unknown, ask or use today), Last Amended is today if changes are made, otherwise keep previous

For each principle, collect:

1. Name: A concise principle name (e.g., "Library-First", "Test-Driven", "User Privacy")
2. Description: Declarative rules explaining the principle (must be declarative, not imperative)

Step 3: Version Management

Apply semantic versioning to the constitution:

• MAJOR (X.0.0): Incompatible changes — a principle removed, fundamentally reworded, or contradicted
• MINOR (0.X.0): Backward-compatible additions — new principle added, expanded description
• PATCH (0.0.X): Clarifications — typo fixes, wording improvements that don't change meaning

For a new constitution, set version to 1.0.0. For updates, determine the appropriate bump.

Step 4: Generate Constitution

Write the completed .speckit/constitution.md:

# [PROJECT_NAME] Constitution

## Core Principles

### I. [Principle 1 Name]
[Declarative description of the principle — what MUST always be true, key rules, rationale]

### II. [Principle 2 Name]
[Declarative description of the principle]

### III. [Principle 3 Name]
[Declarative description of the principle]

### IV. [Principle 4 Name]
[Declarative description of the principle]

### V. [Principle 5 Name]
[Declarative description of the principle]

## [Additional Section if needed, e.g., Development Workflow, Security Requirements]

[Section content]

## Governance

[Governance rules: how decisions are made, how constitution is amended, versioning policy, compliance review expectations]

**Version**: [VERSION] | **Ratified**: [DATE] | **Last Amended**: [DATE]

Step 5: Consistency Propagation

After updating the constitution, check consistency with dependent templates:

• Read .speckit/plan-template.md — ensure "Constitution Check" section aligns with updated principles
• Read .speckit/spec-template.md — check if any mandatory sections need updating
• Read .speckit/tasks-template.md — ensure task categorization reflects principle-driven requirements

Step 6: Sync Impact Report

If updating an existing constitution, output a summary:

Constitution Update Summary:
  Version: [OLD] → [NEW] ([BUMP TYPE])
  Rationale: [Why this version bump was chosen]

  Modified Principles: [list if any]
  Added Sections: [list if any]
  Removed Sections: [list if any]

  Templates Requiring Review:
    [✅ Updated / ⚠ Check manually]: .speckit/plan-template.md
    [✅ Updated / ⚠ Check manually]: .speckit/spec-template.md

  Suggested commit: "docs(constitution): amend to v[VERSION] - [brief description]"

Step 7: Output Summary

Constitution [created/updated]: [PROJECT_NAME]
Version: [VERSION]

Principles:
  I.   [Name] — [One-line summary]
  II.  [Name] — [One-line summary]
  III. [Name] — [One-line summary]
  IV.  [Name] — [One-line summary]
  V.   [Name] — [One-line summary]

Next step: Run /spec-kit:specify to create your first feature specification.

Validation Rules

• Principles are required (typically 3-7; respect user preference)
• All principles must be declarative statements, not imperative commands
• Principles should be specific enough to validate compliance: prefer "MUST" over "should"
• No unexplained brackets [...] should remain in the final output
• Dates must be in ISO format (YYYY-MM-DD)
• Version must follow semantic versioning (X.Y.Z)
• If the user provides fewer principles than needed, help derive additional ones from project context (tech stack, team size, domain)
• If any principles remain ambiguous, insert TODO(<FIELD_NAME>): explanation and document in the sync report