setting-up-constitution

## 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.