constitution

$ARGUMENTS

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

Outline

You are updating the project constitution at .specswarm/constitution.md. This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. [PROJECT_NAME], [PRINCIPLE_1_NAME]). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.

Follow this execution flow:

1. Load the existing constitution template at .specswarm/constitution.md.

   • Identify every placeholder token of the form [ALL_CAPS_IDENTIFIER]. IMPORTANT: The user might require less or more principles than the ones used in the template. If a number is specified, respect that - follow the general template. You will update the doc accordingly.

2. Collect/derive values for placeholders:

   • First, read README.md for project context (if it exists):
     • Use the Read tool to read README.md
     • Extract project name from first heading (e.g., # My Project → "My Project")
     • Extract project description from first paragraph after title
     • Look for sections like "Goals", "Vision", "Purpose", "Standards", "Conventions" for principle guidance
     • If README.md doesn't exist or lacks content, skip this step
   • If user input (conversation) supplies a value, use it (takes priority over README).
   • Otherwise infer from README context (gathered above) or prior constitution versions if embedded.
   • For governance dates: RATIFICATION_DATE is the original adoption date (if unknown ask or mark TODO), LAST_AMENDED_DATE is today if changes are made, otherwise keep previous.
   • CONSTITUTION_VERSION must increment according to semantic versioning rules:
     • MAJOR: Backward incompatible governance/principle removals or redefinitions.
     • MINOR: New principle/section added or materially expanded guidance.
     • PATCH: Clarifications, wording, typo fixes, non-semantic refinements.
   • If version bump type ambiguous, propose reasoning before finalizing.

3. Draft the updated constitution content:

   • Replace every placeholder with concrete text (no bracketed tokens left except intentionally retained template slots that the project has chosen not to define yet—explicitly justify any left).
   • Preserve heading hierarchy and comments can be removed once replaced unless they still add clarifying guidance.
   • Ensure each Principle section: succinct name line, paragraph (or bullet list) capturing non‑negotiable rules, explicit rationale if not obvious.
   • Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.

4. Consistency propagation checklist (convert prior checklist into active validations):

   • Read /templates/plan-template.md and ensure any "Constitution Check" or rules align with updated principles.
   • Read /templates/spec-template.md for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
   • Read /templates/tasks-template.md and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
   • Read each command file in /templates/commands/*.md (including this one) to verify no outdated references (agent-specific names like CLAUDE only) remain when generic guidance is required.
   • Read any runtime guidance docs (e.g., docs/quickstart.md, or agent-specific guidance files if present). Update references to principles changed. Note: README.md is already read in Step 2.

5. Produce a Sync Impact Report (prepend as an HTML comment at top of the constitution file after update):

   • Version change: old → new
   • List of modified principles (old title → new title if renamed)
   • Added sections
   • Removed sections
   • Templates requiring updates (✅ updated / ⚠ pending) with file paths
   • Follow-up TODOs if any placeholders intentionally deferred.