constitution
Skill98 starsChanged 9 months agoMITView on GitHub
Create or update the project constitution - personalized governance and coding principles. Use when starting a project or updating project standards. Triggers on: create constitution, update principles, set project rules.
We split this skill into the rules it gives an agent
25 rules. 0 are common, 19 are distinctive, and 6 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
19
Distinctive
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Create a personalized project constitution that defines your team's coding principles, patterns, and governance.
- Distinctive: line 14
Ask the user about their project's coding philosophy and standards
- Distinctive: line 18
Ensure consistency with project templates and documentation
- Very specific: line 26
If relentless/constitution.md and/or relentless/prompt.md already exist:
- Very specific: line 31
Check version in existing constitution.md (look for <!-- TEMPLATE_VERSION: X.Y.Z --> or Template Version:)
- Distinctive: line 32
Check generated date in existing prompt.md
- Distinctive: line 37
Check template VERSION comments for changes
- Distinctive: line 40
If template version > existing version → Offer upgrade
- Distinctive: line 41
If template has new sections → Offer selective merge
- Distinctive: line 42
If quality commands changed → Offer prompt.md refresh
- Very specific: line 66
Update LAST_AMENDED_DATE to today
- Distinctive: line 72
Ask essential questions about the project:
- Distinctive: line 106
Add/remove principles based on project needs (template is a starting point)
- Distinctive: line 107
Ensure each principle has:
- Distinctive: line 113
Add governance section with amendment procedures
- Distinctive: line 119
Read and analyze project documentation:
- Very specific: line 145
Create a personalized prompt.md with:
- Distinctive: line 175
Test-first workflow (write tests BEFORE implementation)
- Distinctive: line 212
All dates in ISO format (YYYY-MM-DD)
- Very specific: line 217
All quality commands are actual commands from package.json
- Distinctive: line 219
No generic placeholders remain
- Distinctive: line 233
If validation fails, fix the errors and re-run
- Very specific: line 261
If relentless/constitution.md or relentless/prompt.md exist:
- Distinctive: line 265
Ask what needs to change
- Distinctive: line 271
Add amendment notes at top
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Project Constitution Generator
Create a personalized project constitution that defines your team's coding principles, patterns, and governance.
The Job
- Ask the user about their project's coding philosophy and standards
- Analyze the project structure and documentation
- Generate personalized constitution based on their answers →
relentless/constitution.md - Generate personalized agent prompt based on the same analysis →
relentless/prompt.md - Ensure consistency with project templates and documentation
Important: The constitution is the foundation for all feature work - create this before generating features.
Upgrade Detection (For Existing Users)
If relentless/constitution.md and/or relentless/prompt.md already exist:
Step 0: Check for Template Updates
- Read current files:
- Check version in existing constitution.md (look for
<!-- TEMPLATE_VERSION: X.Y.Z -->or**Template Version:**) - Check generated date in existing prompt.md
- Check version in existing constitution.md (look for
- Compare with templates:
- Read
.claude/skills/constitution/templates/constitution.md - Read
.claude/skills/constitution/templates/prompt.md - Check template VERSION comments for changes
- Read
- Detect changes:
- If template version > existing version → Offer upgrade
- If template has new sections → Offer selective merge
- If quality commands changed → Offer prompt.md refresh
- Offer upgrade options:
## Upgrade Available Your constitution.md is v2.0.0, template is v2.1.0. Changes in v2.1.0: - Added SpecKit workflow documentation - Enhanced TDD requirements - Added quality gates section Options: A. Full upgrade (backup existing, apply template changes) B. Selective merge (show diff, choose sections) C. Skip upgrade (keep existing) D. Regenerate from scratch (lose customizations) - If upgrading:
- Backup existing files to
*.backup - Apply template changes preserving customizations
- Update version number
- Update
LAST_AMENDED_DATEto today
- Backup existing files to
Step 1: Gather Project Information
Ask essential questions about the project:
Project Identity:
- Project name?
- Primary programming language(s)?
- Tech stack (frameworks, libraries)?
Testing Philosophy:
- Testing approach? (TDD, test after, pragmatic)
- Required test coverage?
- Testing frameworks preferred?
Code Quality:
- Linting/formatting tools?
- Required checks before commit? (typecheck, lint, test)
- Code review requirements?
Architecture Principles:
- Preferred patterns? (MVC, clean architecture, etc.)
- Modularity requirements?
- Performance expectations?
Version Control:
- Branch naming conventions?
- Commit message format?
- CI/CD requirements?
Step 2: Generate Constitution
Load the template from templates/constitution.md and:
- Replace all
[PLACEHOLDER]tokens with concrete values from user answers - Add/remove principles based on project needs (template is a starting point)
- Ensure each principle has:
- MUST rules (enforced, blocking)
- SHOULD rules (best practices, warnings)
- Clear rationale
- Set version to
1.0.0for new constitutions - Set ratification date to today
- Add governance section with amendment procedures
Step 3: Analyze Project Structure
Read and analyze project documentation:
Core Files:
README.md- Project overview, setup instructionsAGENTS.mdorCLAUDE.md- Developer guidelinespackage.json- Scripts, dependencies, tech stackCONTRIBUTING.md- Contribution workflow (if exists)
Extract:
- Tech stack (TypeScript, React, Node, etc.)
- Testing framework (vitest, jest, playwright)
- Quality commands (
typecheck,lint,test) - Build system (bun, npm, turbo, vite)
- Linting setup (eslint, biome)
- File structure patterns
Step 4: Generate Personalized Prompt
Load the base template from templates/prompt.md and personalize it:
Must include spec/plan/tasks awareness so the agent reads spec.md and plan.md in full before execution, and reads only the relevant user story section from tasks.md for the current story.
Base Template Location: templates/prompt.md
Create a personalized prompt.md with:
Section 1: Quality Gates
## CRITICAL: Quality Gates (Non-Negotiable)
Before marking ANY story as complete:
\`\`\`bash
# TypeScript (detected from package.json)
[actual typecheck command from package.json scripts]
# Linting (detected from package.json)
[actual lint command from package.json scripts]
# Tests (detected from package.json)
[actual test command from package.json scripts]
\`\`\`
**If ANY check fails, DO NOT mark the story as complete.**Section 2: Project-Specific Patterns (from README/AGENTS.md)
- Monorepo structure (if applicable)
- Component locations
- Test file patterns
- Database/backend info
- Styling approach
Section 3: TDD Workflow (MANDATORY)
- Test-first workflow (write tests BEFORE implementation)
- Test location patterns
- Test commands
- Verification that tests FAIL before implementation
Section 4: Routing Awareness
- Explanation of routing metadata in prd.json
- Complexity levels (simple/medium/complex/expert)
- Cost optimization modes (free/cheap/good/genius)
Section 5: SpecKit Workflow
- Full workflow: specify → plan → tasks → convert → analyze → implement
- Artifact awareness: spec.md, plan.md, tasks.md, checklist.md, prd.json
Section 6: Common Pitfalls (from AGENTS.md/docs)
- Project-specific gotchas
- Known issues
- Best practices
Footer:
---
**Personalized for [Project Name]**
**Generated:** [date]
**Re-generate:** /relentless.constitutionSave to: relentless/prompt.md
Step 5: Validate & Save
Before saving:
Constitution:
- No
[PLACEHOLDER]tokens remain - All dates in ISO format (YYYY-MM-DD)
- Principles are declarative and testable
- Version format is semantic (X.Y.Z)
Prompt:
- All quality commands are actual commands from package.json
- File patterns match project structure
- No generic placeholders remain
Save both files:
relentless/constitution.mdrelentless/prompt.md
Run the validators to ensure both files are correctly formatted:
# Validate constitution.md
.claude/skills/validators/scripts/validate-constitution.sh "relentless/constitution.md"
# Validate prompt.md
.claude/skills/validators/scripts/validate-prompt.sh "relentless/prompt.md"- If validation fails, fix the errors and re-run
- Warnings are acceptable but should be reviewed
Step 6: Report
Output summary:
✓ Created constitution.md
- Version: 1.0.0
- Principles: [count]
- Key rules: [summary]
✓ Created prompt.md
- Quality gates: [count]
- Tech stack: [detected stack]
- Test framework: [detected]
Next steps:
1. Review both files
2. Create your first feature: /relentless.specify "feature description"Updating Existing Files
If relentless/constitution.md or relentless/prompt.md exist:
For Constitution Updates:
- Load current version
- Ask what needs to change
- Increment version appropriately:
- MAJOR: Breaking changes to principles
- MINOR: New principles added
- PATCH: Clarifications, typo fixes
- Update
LAST_AMENDED_DATEto today - Add amendment notes at top
For Prompt Updates:
- Re-analyze project structure (package.json, docs)
- Detect any new quality commands or patterns
- Regenerate personalized sections
- Preserve any manual customizations in comments
- Update "Generated" date
Both files can be regenerated at any time by running /relentless.constitution again.
Example Constitution Structure
# Project Constitution
**Version:** 1.0.0
**Ratified:** 2026-01-11
**Last Amended:** 2026-01-11
## Principles
### Principle 1: Type Safety
**MUST:**
- All code must pass TypeScript strict mode
- No `any` types except in documented cases
**SHOULD:**
- Use Zod for runtime validation
- Prefer inference over explicit types
**Rationale:** Type safety prevents runtime errors and improves maintainability.
### Principle 2: Testing
**MUST:**
- All features must have unit tests
- CI must pass before merging
**SHOULD:**
- Aim for 80% coverage
- Write tests before implementation (TDD)
**Rationale:** Tests document behavior and prevent regressions.
## Governance
**Amendment Process:**
1. Propose changes via PR
2. Discuss with team
3. Update version semantically
4. Document rationale
**Compliance:**
- Constitution checked before each feature implementation
- Violations block PR mergeOther versions6 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 6
- mehrad-dm/mastermind★ 23same name
- qyndex/claude-init★ 2same name
- KazukiShinomiya/sdd-starter★ 1same name
- njt2810/claude-code-framework★ 1same name
- angelgabrieljacintohuayllasco/clipboard-skills★ 0same name
- crustacean-dev/knowledge-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository15 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- analyzeSkill
- checklistSkill
- clarifySkill
- convertSkill
- implementSkill
- learnSkill
- planSkill
- prdSkill
- relentlessSkill
- specifySkill
- tasksSkill
- taskstoissuesSkill
- validatorsSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

