speckit-constitution-zh

User input

$ARGUMENTS

Before continuing, youmustconsider the user input (if it is not empty).

Outline

You are updating the project charter located at .specify/memory/constitution.md . This file is derived from a templateassets/constitution-template.mdand contains placeholder tokens in square brackets (for example [项目名称]、[原则_1_名称]). Your job is to: (a) collect/derive concrete values, (b) fill in the template precisely, and (c) propagate any revisions across dependent artifacts.

Follow this execution flow:

1. Copy all files in assets/specify/ (including subdirectories) to the.specify directory under the repository root while preserving the original directory structure, skipping existing files, andmust not overwrite existing files with the same name. The -n (--no-clobber) option of the cp command can prevent overwriting existing files. At this stage, your project folder contents should resemble the following:

仓库根目录
└── .specify
    ├── memory
    │  └── constitution.md
    ├── scripts
    │  ├──bash    
    │  │  ├── check-prerequisites.sh
    │  │  ├── common.sh
    │  │  ├── create-new-feature.sh
    │  │  ├── setup-plan.sh
    │  │  └── update-claude-md.sh
    │  ├──powershell    
    │  │  ├── check-prerequisites.ps1
    │  │  ├── common.ps1
    │  │  ├── create-new-feature.ps1
    │  │  ├── setup-plan.ps1
    │  │  └── update-claude-md.ps1    
    ├── specs
    │  └── 001-create-taskify
    │      └── spec.md
    └── templates
        ├── plan-template.md
        ├── spec-template.md
        └── tasks-template.md

1. Load the existing charter template located at relative to the repository root .specify/memory/constitution.md .

   • Identify every placeholder token of the form [ALL_CAPS_IDENTIFIER] . Important: The user may need fewer or more principles than are used in the template. If a number is specified, comply with that number - follow the generic template. You will update the document accordingly.

2. Collect/derive the values for the placeholders:

   • If the user input (conversation) provides a value, use it.
   • Otherwise infer from existing repository context (README, documentation, embedded previous charter versions).
   • For governance dates:批准日期 is the original adoption date (if unknown, ask or mark TODO), and if there are changes then 最后修订日期 is today, otherwise keep the previous date.
   • 章程版本 must be incremented according to semantic versioning rules:
     • Major version: backward-incompatible governance/principle removals or redefinitions.
     • Minor version: adding new principles/sections or materially expanding guidance.
     • Patch: clarifications, wording, typo fixes, non-semantic refinements.
   • If the version bump type is unclear, provide a rationale before finalizing.

3. Draft the updated charter content:

   • Replace every placeholder with concrete text (except template slots intentionally left because project choices are not yet defined - explicitly state any remaining placeholders).
   • Preserve the heading hierarchy, and once replacements are made, comments may be removed unless they still provide clarifying guidance.
   • Ensure each principle section has: a concise name line, a paragraph (or bullet list) capturing the non-negotiable rules, and an explicit rationale if it is not obvious.
   • Ensure the governance section lists the amendment procedure, versioning policy, and compliance review expectations.

4. Consistency propagation checklist (convert the previous checklist into active verification):

   • Read .specify/templates/plan-template.md and ensure any "charter checks" or rules are consistent with the updated principles.
   • Read .specify/templates/spec-template.md To align scope/requirements — update if the charter adds/removes mandatory sections or constraints.
   • Read .specify/templates/tasks-template.md and ensure the task classification reflects newly added or removed principle-driven task types (e.g., observability, version control, test discipline).
   • Read any runtime guidance documents (e.g., README.md、docs/quickstart.md or existing agent-specific guidance files). Update references to changed principles.

5. Generate a sync impact report (prepended as an HTML comment at the top of the charter file after updates):

   • Version change: old → new
   • List of modified principles (old title → new title if renamed)
   • Added sections
   • Removed sections
   • Templates requiring updates (✅ updated / ⚠ pending) and file paths
   • If any placeholders are intentionally deferred, list follow-up to-dos.

6. Validation before final output:

   • No unexplained bracket tokens remain.
   • Version line matches the report.
   • Date is in ISO format YYYY-MM-DD.
   • Principles are declarative, testable, and free of vague language ("should" → replaced with MUST/SHOULD rationale where appropriate).

7. Write the completed charter back to .specify/memory/constitution.md(overwrite).

8. Output the final summary to the user:

• New version and upgrade rationale.
• Any files marked for manual follow-up.
• Suggested commit message (e.g.,docs: 修订章程至 vX.Y.Z（原则添加 + 治理更新））。

Formatting and style requirements:

• Use Markdown headings exactly as in the template (do not demote/promote levels).
• Wrap long rationale lines to maintain readability (ideally <100 characters), but do not enforce with hard line breaks.
• Keep a single blank line between sections.
• Avoid trailing whitespace.

If the user provides a partial update (e.g., revising only one principle), still perform the validation and version decision steps.

If critical information is missing (e.g., the ratification date is truly unknown), insert TODO(<FIELD_NAME>): explanation and include it under deferred items in the sync impact report.

Do not create new templates; always operate on the existing .specify/memory/constitution.md file.