speckit-constitution-zh

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

用户输入

User Input

text

$ARGUMENTS

在继续之前，您必须考虑用户输入（如果不为空）。

text

$ARGUMENTS

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

大纲

Outline

您正在更新位于

.specify/memory/constitution.md

的项目章程。此文件源自一个模板assets/constitution-template.md，包含方括号中的占位符令牌（例如

[项目名称]

、

[原则_1_名称]

）。您的工作是：(a) 收集/推导具体值，(b) 精确填充模板，以及 (c) 在依赖工件中传播任何修订。

遵循此执行流程：

将
```
assets/specify/
```
所有文件（包括子目录）按原目录结构复制到仓库根目录下的
```
.specify
```
目录，跳过已有文件，不能覆盖原有同名文件。cp命令的 -n（--no-clobber）选项可以防止覆盖已存在的文件。在此阶段，您的项目文件夹内容应类似于以下内容：

text

仓库根目录
└── .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

加载位于相对仓库根目录
```
.specify/memory/constitution.md
```
的现有章程模板。
- 识别形式为
```
[ALL_CAPS_IDENTIFIER]
```
  的每个占位符令牌。重要：用户可能需要比模板中使用的更少或更多的原则。如果指定了数量，请遵守该数量 - 遵循通用模板。您将相应地更新文档。
收集/推导占位符的值：
- 如果用户输入（对话）提供了值，则使用它。
- 否则从现有仓库上下文推断（README、文档、嵌入的先前章程版本）。
- 对于治理日期：
```
批准日期
```
  是原始采用日期（如果未知则询问或标记 TODO），如果有更改则
```
最后修订日期
```
  是今天，否则保持之前的日期。
- ```
章程版本
```
  必须根据语义版本规则递增：
  - 主版本：向后不兼容的治理/原则删除或重新定义。
  - 次版本：添加新原则/章节或实质性扩展指导。
  - 补丁：澄清、措辞、拼写错误修复、非语义性优化。
- 如果版本升级类型不明确，在最终确定前提出理由。
起草更新的章程内容：
- 用具体文本替换每个占位符（除了项目选择尚未定义而有意保留的模板槽位——明确说明任何剩余的占位符）。
- 保留标题层次结构，一旦替换可以移除注释，除非它们仍然提供澄清指导。
- 确保每个原则部分：简洁的名称行，段落（或项目符号列表）捕捉不可协商的规则，如果不是显而易见则提供明确的理由。
- 确保治理部分列出修订程序、版本策略和合规审查期望。
一致性传播检查清单（将先前检查清单转换为积极验证）：
- 读取
```
.specify/templates/plan-template.md
```
  并确保任何"章程检查"或规则与更新的原则一致。
- 读取
```
.specify/templates/spec-template.md
```
  以对齐范围/要求——如果章程添加/删除强制性章节或约束则更新。
- 读取
```
.specify/templates/tasks-template.md
```
  并确保任务分类反映新增或删除的原则驱动任务类型（例如，可观察性、版本控制、测试纪律）。
- 读取任何运行时指导文档（例如
```
README.md
```
  、
```
docs/quickstart.md
```
  或存在的特定代理指导文件）。更新对已更改原则的引用。
生成同步影响报告（在更新后作为 HTML 注释预置在章程文件顶部）：
- 版本变更：旧 → 新
- 修改的原则列表（旧标题 → 新标题如果重命名）
- 新增章节
- 删除章节
- 需要更新的模板（✅ 已更新 / ⚠ 待处理）及文件路径
- 如果有任何占位符被故意推迟，则列出后续待办事项。
最终输出前的验证：
- 没有剩余未解释的括号令牌。
- 版本行与报告匹配。
- 日期为 ISO 格式 YYYY-MM-DD。
- 原则是陈述性的、可测试的，并且没有模糊语言（"应该" → 在适当地方替换为 MUST/SHOULD 理由）。
将完成的章程写回到
```
.specify/memory/constitution.md
```
（覆盖）。
向用户输出最终摘要：

新版本和升级理由。
任何标记为手动跟进的文件。

建议的提交消息（例如，

docs: 修订章程至 vX.Y.Z（原则添加 + 治理更新）

）。

格式化和样式要求：

完全按照模板中的 Markdown 标题使用（不要降级/升级级别）。
包装长理由行以保持可读性（理想情况下 <100 个字符），但不要用生硬的断行强制执行。
在章节之间保持单个空行。
避免尾随空白。

如果用户提供部分更新（例如，仅修订一个原则），仍需执行验证和版本决策步骤。

如果关键信息缺失（例如，批准日期确实未知），插入

TODO(<FIELD_NAME>): explanation

并在同步影响报告的延期项目下包含。

不要创建新模板；始终在现有的

.specify/memory/constitution.md

文件上操作。

You are updating the project charter located at

.specify/memory/constitution.md

. This file is derived from a template assets/constitution-template.md and contains placeholder tokens in square brackets (e.g.,

[Project Name]

[Principle_1_Name]

). Your tasks are to: (a) collect/infer specific values, (b) accurately populate the template, and (c) propagate any revisions across dependent artifacts.

Follow this execution workflow:

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:

text

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

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.
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.
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.
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.
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.
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).
Write the completed charter back to
```
.specify/memory/constitution.md
```
(overwrite).
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)
```
  ).

Formatting and Style Requirements:

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.

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

If critical information is missing (e.g., approval date is truly unknown), insert

TODO(<FIELD_NAME>): explanation

and include it under deferred items in the synchronization impact report.

Do not create new templates; always operate on the existing

.specify/memory/constitution.md

file.