---
name: setting-up-constitution
description: |
  Creates or updates the project constitution that defines migration principles, constraints, and conventions.
  Triggers: "set up constitution", "define migration principles", "create project rules", "establish conventions", "establish migration constitution".
  NOT for: implementation, implementation planning, task generation.
---

## User Input

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

## Mandatory Principles

## Outline

You are creating or updating the project constitution to your task's artifact path (the `Artifact path:` from task metadata). Write `constitution.md` there. 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 `skills/setting-up-constitution/templates/constitution-template.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:
   - If user input (conversation) supplies a value, use it.
   - If knowledge graph or constitution history contains relevant info, infer from there.
   - Otherwise infer from existing repo context (README, docs, prior constitution versions if embedded).
     - [If exists] Read `context.md` or similar for any runtime guidance that may inform principle definitions.
   - **DO NOT read source code files** (.java, .ts, .py, .cs, etc.). Constitution is a high-level governance document. You only need: project structure (directory tree), build files (pom.xml, package.json, build.gradle), config files (application.yml, web.xml), and documentation (README, docs/). If you need to understand the tech stack or architecture patterns, read the top-level build file and directory structure — never individual source files.
   - 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 `skills/creating-implementation-plan/templates/plan-template.md` and ensure any "Constitution Check" or rules align with updated principles.
   - Read `skills/feature-inventory/templates/spec-template.md` for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
   - Read `skills/breaking-down-tasks/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 `skills/*/SKILL.md` to verify no outdated references remain when generic guidance is required.
   - Read any runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`, or agent-specific guidance files if present). Update references to principles changed.

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.

6. Validation before final output:
   - No remaining unexplained bracket tokens.
   - Version line matches report.
   - Dates ISO format YYYY-MM-DD.
   - Principles are declarative, testable, and free of vague language ("should" → replace with MUST/SHOULD rationale where appropriate).

7. Write the completed constitution to your artifact path (overwrite).

8. Output a final summary to the user with:
   - New version and bump rationale.
   - Any files flagged for manual follow-up.
   - Suggested commit message (e.g., `docs: amend constitution to vX.Y.Z (principle additions + governance update)`).

## Formatting & Style Requirements

- Use Markdown headings exactly as in the template (do not demote/promote levels).
- Wrap long rationale lines to keep readability (<100 chars ideally) but do not hard enforce with awkward breaks.
- Keep a single blank line between sections.
- Avoid trailing whitespace.
- If the user supplies partial updates (e.g., only one principle revision), still perform validation and version decision steps.
- If critical info missing (e.g., ratification date truly unknown), insert `TODO(<FIELD_NAME>): explanation` and include in the Sync Impact Report under deferred items.
- Do not create a new template; always operate on the existing constitution file at the provided path.