agentleFS
cnoe-iocnoe-io/ai-platform-engineering/.claude/skills/speckit.constitution/SKILL.md

speckit.constitution

Skill438 starsChanged 54 days agoApache-2.0View on GitHub

You MUST consider the user input before proceeding (if not empty). The constitution is the governing document for the project. It defines core principles, development workflow, and governance rules that all agents and engineers must follow. It lives at docs/plans/CONSTITUTION.md and is symlinked from .specify/memory/constitution.md. Check whether docs/plans/CONSTITUTION.md exists: If the user input is empty: Verify the symlink resolves correctly.

3 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. About 0 are common, 12 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈12

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Check whether docs/plans/CONSTITUTION.md exists:

    line 31
  2. Distinctive:

    If the user input is empty:

    line 36
  3. Distinctive:

    Read README.md (if it exists) for project purpose and scope

    line 46
  4. Very specific:

    Read docs/plans/ARCHITECTURE.md (if it exists) for technical context

    line 47
  5. Distinctive:

    Use the user's input for principles and values

    line 48
  6. Distinctive:

    Add or remove principle sections as needed (the template shows 5 examples but the actual count depends on the project)

    line 53
  7. Distinctive:

    Quality checks: before writing:

    line 58
  8. Distinctive:

    Every principle must be actionable (agents can verify compliance)

    line 59
  9. Very specific:

    No placeholder text remains ([PLACEHOLDER] markers)

    line 60
  10. Distinctive:

    Verify the symlink resolves correctly.

    line 74
  11. Distinctive:

    If the constitution requires a specification for amendments, note this requirement to the user

    line 88
  12. Distinctive:

    If the amendment contradicts an existing principle, highlight the conflict and ask the user to confirm

    line 89
  13. Very specific:

    Update [LAST_AMENDED_DATE] to today's date

    line 95
  14. Distinctive:

    Never remove the Governance section.

    line 131
  15. Distinctive:

    Keep principles concise and actionable.

    line 132
  16. Distinctive:

    Use numbered Roman numerals (I, II, III...) for principle headings to match convention

    line 133

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md
<!-- Create or amend the project constitution --><!-- AUTO-GENERATED — DO NOT EDIT --><!-- Source: .specify/templates/commands/constitution.md --><!-- Regenerate: make generate-agent-files -->

description: Create or amend the project constitution handoffs:

  • label: Create Feature Spec agent: speckit.specify prompt: Create a spec for...
  • label: Review Architecture agent: speckit.plan prompt: Review architecture alignment with constitution

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Outline

The constitution is the governing document for the project. It defines core principles, development workflow, and governance rules that all agents and engineers must follow. It lives at docs/plans/CONSTITUTION.md and is symlinked from .specify/memory/constitution.md.

Step 1: Determine Mode

Check whether docs/plans/CONSTITUTION.md exists:

  • If it does NOT exist → Create mode (go to Step 2)
  • If it exists → Amend mode (go to Step 3)

If the user input is empty:

  • In create mode: ask the user to describe the project's purpose, core values, and any non-negotiable constraints
  • In amend mode: ask the user what they want to change and why

Step 2: Create New Constitution

  1. Load the template from templates/constitution-template.md to understand the required structure and sections.
  2. Gather project context:
    • Read README.md (if it exists) for project purpose and scope
    • Read docs/plans/ARCHITECTURE.md (if it exists) for technical context
    • Use the user's input for principles and values
  3. Fill the template by replacing all [PLACEHOLDER] tokens with concrete content derived from the project context and user input:
    • Replace [PROJECT_NAME] with the actual project name
    • Replace each [PRINCIPLE_N_NAME] and [PRINCIPLE_N_DESCRIPTION] with real principles
    • Add or remove principle sections as needed (the template shows 5 examples but the actual count depends on the project)
    • Replace [SECTION_2_NAME], [SECTION_3_NAME] and their content with appropriate sections for the project
    • Fill [GOVERNANCE_RULES] with concrete governance rules
    • Set [CONSTITUTION_VERSION] to 0.0.1, [RATIFICATION_DATE] and [LAST_AMENDED_DATE] to today's date
  4. Quality checks before writing:
    • Every principle must be actionable (agents can verify compliance)
    • No placeholder text remains ([PLACEHOLDER] markers)
    • At least 3 core principles are defined
    • Governance section defines how amendments work
    • Version and dates are set
  5. Write the constitution to docs/plans/CONSTITUTION.md.
  6. Ensure the symlink exists at .specify/memory/constitution.md pointing to ../../docs/plans/CONSTITUTION.md:

    mkdir -p .specify/memory
    ln -sf ../../docs/plans/CONSTITUTION.md .specify/memory/constitution.md

    Verify the symlink resolves correctly.

  7. Go to Step 4.

Step 3: Amend Existing Constitution

  1. Load the current constitution from docs/plans/CONSTITUTION.md.
  2. Parse the user's amendment request from the input. Identify:
    • Which section(s) the change affects
    • Whether this adds, modifies, or removes content
    • The rationale for the change
  3. Validate the amendment against governance rules defined in the constitution itself:
    • If the constitution requires a specification for amendments, note this requirement to the user
    • If the amendment contradicts an existing principle, highlight the conflict and ask the user to confirm
  4. Apply the amendment:
    • Modify only the affected sections
    • Preserve all unaffected content exactly as-is
    • Increment the version number (patch for clarifications, minor for new principles, major for fundamental changes)
    • Update [LAST_AMENDED_DATE] to today's date
  5. Present a summary of changes to the user:

    ## Constitution Amendment Summary
    
    **Version**: X.Y.Z → X.Y.Z+1
    **Sections changed**: [list]
    **Changes**:
    - [description of each change]
    **Rationale**: [from user input]
  6. Write the updated constitution to docs/plans/CONSTITUTION.md.
  7. Go to Step 4.

Step 4: Report Completion

Report the result with:

  • Mode used (create or amend)
  • Constitution file path (docs/plans/CONSTITUTION.md)
  • Symlink status (.specify/memory/constitution.md → valid/invalid)
  • Version number
  • Summary of principles defined
  • Next steps: suggest /speckit.specify to create the first feature spec if this is a new constitution

References

  • A Spec for Specs — Outshift Engineering guidance on specification standards and agentic software development

Key Rules

  • The constitution is the highest-authority document in the project — it governs all other docs
  • Never remove the Governance section; it defines how the constitution itself can change
  • Keep principles concise and actionable; agents must be able to verify compliance
  • Use numbered Roman numerals (I, II, III...) for principle headings to match convention
  • The .specify/memory/constitution.md symlink must always point to docs/plans/CONSTITUTION.md

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.