Project Constitution

The user input to you can be provided directly by the agent or as a command argument - you MUST consider it before proceeding with the prompt (if not empty).

User input:

$ARGUMENTS

⚠️ Step 0: Read Template First

Before any other action — read this template now using the Read tool:

.speck/​templates/​project/​constitution-template.md

The template defines required sections and formatting for constitution.md, including principle categories, rationale format, and constraint declarations. Generating it from memory produces structurally incorrect output.

Checkpoint: After reading, note the top-level sections from the template. Then continue to Play Level Check.

Play Level Check

Read .speck/​project.json (if it exists) for play_level.

• Sprint: Tell the user: "Sprint projects don't need a constitution. Ship first, structure later. If you're growing to Platform, run /​project-promote and come back."
• Build: Constitution is optional for Build. Only proceed if the user confirms they want it.
• Platform (or no project.json): Full flow below — constitution is recommended.

---

Define project-specific principles and constraints that will guide all development within this project.

When to use this command:

• Regulated industries (healthcare, finance, government)
• Projects with strict performance/​security requirements
• Multi-team coordination with clear boundaries needed
• High-stakes projects where failure has serious consequences

When to skip:

• Prototypes or MVPs
• Internal tools with flexible requirements
• Well-understood domains with standard practices
• Small projects with single team

1. Load project context:

   • Find active project directory
   • Load project.md to understand project nature and goals
   • Load context.md if exists (constraints and requirements)
   • Check if constitution.md already exists

   Note: Constitution runs BEFORE planning, so PRD.md doesn't exist yet. Use project.md and context.md for guidance.

2. Just-In-Time Research (if needed):

   Reference: Follow the just-in-time research pattern (.cursor/​skills/​just-in-time-research/​SKILL.md)

   Research Areas for Constitution:

   • Security Best Practices: Web search for industry-standard security patterns
   • Technical Principles: Web search for framework-specific best practices
   • Domain Standards: Web search for industry-specific development standards
   • Case Studies: Deep research (if needed) for lessons learned from similar projects

   Document findings in "Research Informing This Constitution" section of output.

3. Analyze project needs for specific principles:

   Domain-Specific Requirements

   • Industry regulations (healthcare, finance, etc.)
   • User safety requirements
   • Data privacy constraints
   • Accessibility standards

   Technical Constraints

   • Performance requirements
   • Platform limitations
   • Integration requirements
   • Security standards

   Business Constraints

   • Time-to-market pressures
   • Budget limitations
   • Team capabilities
   • Stakeholder requirements

   User Experience Principles

   • Target user needs
   • Interaction patterns
   • Brand requirements
   • Localization needs

4. Generate project constitution using the template:

   CRITICAL: Load and follow the template exactly:

   .speck/​templates/​project/​constitution-template.md
   

   Create/​update: specs/​projects/[PROJECT_ID]/​constitution.md

   Notes:

   • Use normative language (MUST/​SHALL/​SHOULD/​MAY) in all principles and standards.
   • Embed any research findings in the template’s "Research Informing This Constitution" section.
   • If updating an existing constitution, preserve unchanged principles and add a short changelog entry.

5. Interactive principle development:

   If no specific requirements provided, ask:

   • "What unique constraints does this project have?"
   • "Are there industry-specific requirements?"
   • "What quality attributes are non-negotiable?"
   • "What would constitute failure for this project?"

6. Principle categories to consider:

   Regulatory Compliance

   • GDPR, HIPAA, SOX, etc.
   • Industry standards
   • Certification requirements

   Quality Attributes

   • Performance (specific metrics)
   • Reliability (uptime requirements)
   • Scalability (growth targets)
   • Maintainability (team constraints)

   User Experience

   • Accessibility (WCAG level)
   • Responsiveness requirements
   • Offline capabilities
   • Cross-platform needs

   Development Process

   • Review requirements
   • Testing standards
   • Documentation needs
   • Deployment constraints

7. Generate validation checklists:

   • Per-story checklist items
   • Per-epic validation gates
   • Project-level success criteria

8. Save as specs/​projects/[PROJECT_ID]/​constitution.md

9. Update references:

   • Add to project.md references section
   • Note in PRD.md compliance section
   • Reference in epic templates

10. Output summary:

✅ Project Constitution Created!

Project: [Name]
Version: 1.0.0

Principles Defined:
1. [Principle Name]: [Focus area]
2. [Principle Name]: [Focus area]
[...]

Validation Points:
- Story level: [X] checks
- Epic level: [Y] gates
- Project level: [Z] criteria

Key Constraints:
- [Constraint type]: [Requirement]
- [Constraint type]: [Requirement]

Next Steps:
1. Review with stakeholders
2. Distribute to team
3. Run /​project-plan to create PRD (will incorporate these principles)
4. Configure automated validation (in CI/​CD)
5. Principles will be enforced in epic/​story development

Note: Constitution provides essential principle inputs for PRD creation.
These principles will guide all technical decisions in /​project-architecture
and be enforced throughout epic and story development.

Note: Project constitutions are living documents. Update as new requirements emerge or constraints change.