speckit-constitution-zh

User Input

$ARGUMENTS

Outline

.specify/memory/constitution.md

[Project Name]

[Principle_1_Name]

1. Copy all files (including subdirectories) from

   assets/specify/

   to the

   .specify

   directory under the repository root, maintaining the original directory structure. Skip existing files, do NOT overwrite 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 content should resemble the following:

Repository Root
└── .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

   .specify/memory/constitution.md

   relative to the repository root.
   • Identify each placeholder token in the form of

     [ALL_CAPS_IDENTIFIER]

     . Important: The user may require fewer or more principles than those used in the template. If a quantity is specified, adhere to it - follow the generic template. You will update the document accordingly.
2. Collect/infer values for placeholders:
   • Use values provided in the user input (conversation) if available.
   • Otherwise, infer from existing repository context (README, documentation, embedded previous charter versions).
   • For governance dates:

     Approval Date

     is the original adoption date (ask or mark as TODO if unknown),

     Last Revised Date

     is today if there are changes, otherwise keep the previous date.

   • Charter Version

     must be incremented according to semantic versioning rules:
     • Major version: Backward-incompatible governance/principle removal or redefinition.
     • Minor version: Addition of new principles/sections or substantial expansion of guidance.
     • Patch: Clarifications, wording adjustments, typo fixes, non-semantic optimizations.
   • If the version upgrade type is unclear, provide justifications before finalizing.
3. Draft updated charter content:
   • Replace each placeholder with specific text (except template slots intentionally left undefined due to undecided project selections - clearly state any remaining placeholders).
   • Preserve the heading hierarchy; remove comments once replaced unless they still provide clarifying guidance.
   • Ensure each principle section includes: a concise name line, a paragraph (or bulleted list) capturing non-negotiable rules, and a clear rationale if not obvious.
   • Ensure the governance section lists revision procedures, versioning strategies, and compliance review expectations.
4. Consistency Propagation Checklist (convert previous checklist to active verification):
   • Read

     .specify/templates/plan-template.md

     and ensure any "charter checks" or rules align with 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 task categories reflect newly added or removed principle-driven task types (e.g., observability, version control, testing 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 Synchronization Impact Report (prepend to the charter file as an HTML comment after updates):
   • Version change: Old → New
   • List of modified principles (old title → new title if renamed)
   • Newly added sections
   • Deleted sections
   • Templates requiring updates (✅ Updated / ⚠ Pending) and file paths
   • List follow-up todos if any placeholders are intentionally deferred.
6. Verification before final output:
   • No unexplained bracket tokens remain.
   • Version line matches the report.
   • Dates are in ISO format YYYY-MM-DD.
   • Principles are declarative, testable, and free of ambiguous language (replace "should" with MUST/SHOULD justifications where appropriate).
7. Write the completed charter back to

   .specify/memory/constitution.md

   (overwrite).
8. Output a final summary to the user:
   • New version and upgrade rationale.
   • Any files marked for manual follow-up.
   • Suggested commit message (e.g.,

     docs: revise charter to vX.Y.Z (principle addition + governance update)

     ).

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

TODO(<FIELD_NAME>): explanation

.specify/memory/constitution.md