speckit-constitution

name	speckit-constitution
description	从交互式或提供的原则输入创建或更新项目章程, 确保所有依赖模板保持同步.
compatibility	Requires spec-kit project structure with .specify/ directory
metadata	{"author":"github-spec-kit","source":"templates/commands/constitution.md"}
disable-model-invocation	true

用户输入

$ARGUMENTS

在继续之前, 你必须考虑用户输入(如果不为空).

概述

你正在更新位于 .specify/memory/constitution.md 的项目章程. 该文件是一个包含方括号占位符标记的模板(例如 [PROJECT_NAME], [PRINCIPLE_1_NAME]). 你的工作是(a)收集/推导具体值, (b)精确填充模板, 以及(c)将任何修改传播到相关依赖项中.

遵循此执行流程:

1. 加载位于 .specify/memory/constitution.md 的现有章程模板.

   • 识别每个 [ALL_CAPS_IDENTIFIER] 形式的占位符标记. 重要提示: 用户可能需要比模板中使用的原则更少或更多. 如果指定了数字, 请遵循该数字 - 遵循通用模板. 你将相应地更新文档.

2. 为占位符收集/推导值:

   • 如果用户输入(对话)提供了值, 则使用它.
   • 否则从现有仓库上下文推断(README, 文档, 先前的章程版本(如果嵌入)).
   • 对于治理日期: RATIFICATION_DATE 是原始采用日期(如果未知, 请询问或标记 TODO), LAST_AMENDED_DATE 是今天(如果进行了更改), 否则保留之前的日期.
   • CONSTITUTION_VERSION 必须根据语义版本控制规则递增:
     • MAJOR(主版本): 向后不兼容的治理/原则删除或重新定义.
     • MINOR(次版本): 新原则/部分添加或实质性扩展指导.
     • PATCH(补丁版本): 澄清, 措辞, 拼写错误修复, 非语义优化.
   • 如果版本递增类型不明确, 请在最终确定之前提出理由.

3. 起草更新后的章程内容:

   • 用具体文本替换每个占位符(除了项目选择尚未定义的故意保留的模板槽位外, 不留下括号标记——明确说明任何保留的槽位).
   • 保留标题层次结构, 一旦替换可以删除注释, 除非它们仍然提供澄清指导.
   • 确保每个原则部分: 简洁的名称行, 捕获不可协商规则的段落(或项目符号列表), 如果不明显则提供明确的理由.
   • 确保治理部分列出修改程序, 版本控制策略和合规审查期望.

4. 一致性传播检查清单(将先前的检查清单转换为主动验证):

   • 读取 .specify/templates/plan-template.md 并确保任何"章程检查"或规则与更新的原则保持一致.
   • 读取 .specify/templates/spec-template.md 进行范围/需求对齐——如果章程添加/删除强制部分或约束, 则更新.
   • 读取 .specify/templates/tasks-template.md 并确保任务分类反映新的或删除的原则驱动的任务类型(例如, 可观测性, 版本控制, 测试纪律).
   • 读取 .specify/templates/commands/*.md 中的每个命令文件(包括此文件)以验证在需要通用指导时没有过时的引用(如仅限 CLAUDE 的代理特定名称).
   • 读取任何运行时指导文档(例如 README.md, docs/quickstart.md 或代理特定指导文件(如果存在)). 更新对已更改原则的引用.

5. 生成同步影响报告(在更新后作为 HTML 注释前置到章程文件顶部):

   • 版本更改: 旧版本 → 新版本
   • 修改的原则列表(如果重命名, 则为旧标题 → 新标题)
   • 添加的部分
   • 删除的部分
   • 需要更新的模板(✅ 已更新 / ⚠ 待处理)及文件路径
   • 如果有任何占位符故意延迟, 则提供后续 TODO.

6. 最终输出前的验证:

   • 没有剩余的未解释的括号标记.
   • 版本行与报告匹配.
   • 日期采用 ISO 格式 YYYY-MM-DD.
   • 原则是声明性的, 可测试的, 并且没有模糊语言("should" → 在适当的地方用 MUST/SHOULD 理由替换).

7. 将完成的章程写回 .specify/memory/constitution.md(覆盖).

8. 向用户输出最终摘要, 包括:

   • 新版本和递增理由.
   • 任何标记为手动后续处理的文件.
   • 建议的提交消息(例如 docs: amend constitution to vX.Y.Z (principle additions + governance update)).

格式和样式要求:

• 完全按照模板使用 Markdown 标题(不要降级/升级级别).
• 换行长理由行以保持可读性(理想情况下 <100 个字符), 但不要用尴尬的换行强制执行.
• 在部分之间保持单个空行.
• 避免尾随空白.

如果用户提供部分更新(例如, 仅一个原则修订), 仍然执行验证和版本决策步骤.

如果缺少关键信息(例如, 批准日期确实未知), 请插入 TODO(<FIELD_NAME>): explanation 并包含在同步影响报告中的延迟项下.

不要创建新模板; 始终操作现有的 .specify/memory/constitution.md 文件.