简单来说：在开始编码之前，先定义清晰的规范（Specification），将业务需求、接口定义、数据模型、业务规则等以结构化、可执行的方式编写，让文档即代码，代码即文档。

传统开发：需求 → 设计文档 → 代码 → 测试（代码是真理，四个环节独立）
规约驱动：需求 → Spec 规约 → 自动生成代码/文档/测试（ 一体化，规约是真理，代码是生成物）关键转变

constitution → specify → plan → tasks → implement
     ↓            ↓         ↓       ↓        ↓
   项目原则   →  功能规范 → 实现计划 → 任务分解 → 代码实现 constitution → specify → plan → tasks → implement     ↓            ↓         ↓       ↓        ↓  架构设计：

- /constitution - 建立项目宪法：定义项目核心原则、技术约束、质量标准
- /specify - 写需求文档：自然语言描述功能需求、AI 自动生成完整规约、质量检测清单与验证
- /clarify - 澄清规约：进行用户需求澄清细节、确认
- /plan - 做技术方案：生成技术栈选型、架构设计、数据模型、API 契约
- /tasks - 任务分解清单：按照用户故事组织、依赖关系分析、并行执行优化
- /analyze - 审核文档: 识别spec.md`、`plan.md`、`tasks.md 不一致性、操作约束、规范分析报告、提供建议与修复
- /implement - 开始干活：逐任务自动执行、进度跟踪、质量验证
 其中最关键的 4 个指令是：/specify、/plan 、/tasks 、/implement 指令。

---
description: 从交互式或提供的原则输入创建或更新项目章程，确保所有依赖模板保持同步
---

 ## 用户输入

 ```text
$ARGUMENTS

```
 在继续之前，你**必须**考虑用户输入（如果不为空）。
 ## 概述
 您正在更新 `/memory/constitution.md` 处的项目章程。此文件是一个模板，包含方括号中的占位符标记（例如 `[PROJECT_NAME]`、`[PRINCIPLE_1_NAME]`）。您的工作是（a）收集/派生具体值，（b）精确填充模板，以及（c）在依赖制品之间传播任何修订。

 遵循此执行流程：

 1. 在 `/memory/constitution.md` 处加载现有章程模板。
   - 识别形式为 `[ALL_CAPS_IDENTIFIER]` 的每个占位符标记。
   **重要**：用户可能需要比模板中使用的原则更少或更多的原则。如果指定了数字，请尊重它 - 遵循一般模板。您将相应地更新文档。

 2. 收集/派生占位符的值：
   - 如果用户输入（对话）提供值，请使用它。
   - 否则从现有仓库上下文（README、docs、先前的章程版本（如果嵌入））推断。
   - 对于治理日期：`RATIFICATION_DATE` 是原始采用日期（如果未知，请询问或标记 TODO），`LAST_AMENDED_DATE` 是今天（如果进行了更改），否则保留以前的。
   - `CONSTITUTION_VERSION` 必须根据语义版本控制规则递增：
     - 主要：向后不兼容的治理/原则删除或重新定义。
     - 次要：添加或实质性扩展的新原则/部分指导。
     - 补丁：澄清、措辞、拼写错误修复、非语义细化。
   - 如果版本碰撞类型模糊，请在最终确定之前提出理由。
   
   
 3. 起草更新的章程内容：
   - 用具体文本替换每个占位符（除了项目选择不定义的有意保留的模板插槽外，没有括号标记 - 明确证明任何剩余的）。
   - 保留标题层次结构，一旦替换，可以删除注释，除非它们仍然添加澄清指导。
   - 确保每个原则部分：简洁的名称行、段落（或项目符号列表）捕获不可协商的规则、明确的理由（如果不明显）。
   - 确保治理部分列出修订程序、版本控制策略和合规性审查期望。
 4. 一致性传播检查清单（将先前的检查清单转换为主动验证）：
   - 阅读 `/templates/plan-template.md` 并确保任何"章程检查"或规则与更新的原则一致。
   - 阅读 `/templates/spec-template.md` 以进行范围/需求对齐 - 如果章程添加/删除强制性部分或约束，则更新。
   - 阅读 `/templates/tasks-template.md` 并确保任务分类反映新的或删除的原则驱动的任务类型（例如，可观察性、版本控制、测试纪律）。
   - 阅读 `/templates/commands/*.md` 中的每个命令文件（包括此文件）以验证在需要通用指导时没有过时的引用（仅特定于代理的名称，如 CLAUDE）。
   - 阅读任何运行时指导文档（例如，`README.md`、`docs/quickstart.md` 或特定于代理的指导文件（如果存在））。更新对更改的原则的引用。

 5. 生成同步影响报告（在更新后作为 HTML 注释添加到章程文件顶部）：
   - 版本更改：旧 → 新
   - 修改的原则列表（如果重命名，则旧标题 → 新标题）
   - 添加的部分
   - 删除的部分
   - 需要更新的模板（✅ 已更新 / ⚠ 待处理）及文件路径
   - 如果有任何占位符有意推迟，则后续 TODO
   
 6. 最终输出前的验证：
   - 没有剩余的未解释的括号标记。
   - 版本行与报告匹配。
   - 日期 ISO 格式 YYYY-MM-DD。
   - 原则是声明性的、可测试的，并且没有模糊的语言（"应该" → 在适当的地方用 MUST/SHOULD 理由替换）。
 7. 将完成的章程写回 `/memory/constitution.md`（覆盖）。
 8. 向用户输出最终摘要：
   - 新版本和碰撞理由。
   - 标记为手动后续的任何文件。
   - 建议的提交消息（例如，`docs: amend constitution to vX.Y.Z (principle additions + governance update)`）。
 格式和样式要求：

 - 完全按照模板中的方式使用 Markdown 标题（不要降级/提升级别）。
- 换行长理由行以保持可读性（理想情况下 <100 个字符），但不要用尴尬的中断强制执行。
- 在部分之间保留一个空行。
- 避免尾随空格。
 如果用户提供部分更新（例如，仅一个原则修订），仍然执行验证和版本决策步骤。
 如果缺少关键信息（例如，批准日期确实未知），请插入 `TODO(<FIELD_NAME>): explanation` 并在同步影响报告的延期项目下包含。
 
 不要创建新模板；始终在现有的 `/memory/constitution.md` 文件上操作。