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)将任何修改传播到相关依赖项中.

遵循此执行流程:

加载位于 .specify/memory/constitution.md 的现有章程模板.
- 识别每个 [ALL_CAPS_IDENTIFIER] 形式的占位符标记. 重要提示: 用户可能需要比模板中使用的原则更少或更多. 如果指定了数字, 请遵循该数字 - 遵循通用模板. 你将相应地更新文档.
为占位符收集/推导值:
- 如果用户输入(对话)提供了值, 则使用它.
- 否则从现有仓库上下文推断(README, 文档, 先前的章程版本(如果嵌入)).
- 对于治理日期: RATIFICATION_DATE 是原始采用日期(如果未知, 请询问或标记 TODO), LAST_AMENDED_DATE 是今天(如果进行了更改), 否则保留之前的日期.
- CONSTITUTION_VERSION 必须根据语义版本控制规则递增:
  - MAJOR(主版本): 向后不兼容的治理/原则删除或重新定义.
  - MINOR(次版本): 新原则/部分添加或实质性扩展指导.
  - PATCH(补丁版本): 澄清, 措辞, 拼写错误修复, 非语义优化.
- 如果版本递增类型不明确, 请在最终确定之前提出理由.
起草更新后的章程内容:
- 用具体文本替换每个占位符(除了项目选择尚未定义的故意保留的模板槽位外, 不留下括号标记——明确说明任何保留的槽位).
- 保留标题层次结构, 一旦替换可以删除注释, 除非它们仍然提供澄清指导.
- 确保每个原则部分: 简洁的名称行, 捕获不可协商规则的段落(或项目符号列表), 如果不明显则提供明确的理由.
- 确保治理部分列出修改程序, 版本控制策略和合规审查期望.
一致性传播检查清单(将先前的检查清单转换为主动验证):
- 读取 .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 或代理特定指导文件(如果存在)). 更新对已更改原则的引用.
生成同步影响报告(在更新后作为 HTML 注释前置到章程文件顶部):
- 版本更改: 旧版本 → 新版本
- 修改的原则列表(如果重命名, 则为旧标题 → 新标题)
- 添加的部分
- 删除的部分
- 需要更新的模板(✅ 已更新 / ⚠ 待处理)及文件路径
- 如果有任何占位符故意延迟, 则提供后续 TODO.
最终输出前的验证:
- 没有剩余的未解释的括号标记.
- 版本行与报告匹配.
- 日期采用 ISO 格式 YYYY-MM-DD.
- 原则是声明性的, 可测试的, 并且没有模糊语言("should" → 在适当的地方用 MUST/SHOULD 理由替换).
将完成的章程写回 .specify/memory/constitution.md(覆盖).
向用户输出最终摘要, 包括:
- 新版本和递增理由.
- 任何标记为手动后续处理的文件.
- 建议的提交消息(例如 docs: amend constitution to vX.Y.Z (principle additions + governance update)).

格式和样式要求:

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

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

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

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

Más de este repositorio

mismo repositorio

speckit-analyze

FavToSkill/douxiaojia

在任务生成后, 对 spec.md, plan.md 和 tasks.md 执行非破坏性的跨制品一致性和质量分析.

2026-04-177

speckit-checklist

FavToSkill/douxiaojia

基于用户需求为当前功能生成自定义检查清单.

2026-04-177

speckit-clarify

FavToSkill/douxiaojia

通过提出最多 5 个高度针对性的澄清问题, 识别当前功能规范中未充分说明的领域, 并将答案编码回规范中.

2026-04-177

speckit-implement

FavToSkill/douxiaojia

通过处理并执行 tasks.md 中定义的所有任务来执行实施计划

2026-04-177

speckit-plan

FavToSkill/douxiaojia

使用计划模板执行实施计划工作流, 生成设计制品.

2026-04-177

speckit-specify

FavToSkill/douxiaojia

根据自然语言功能描述创建或更新功能规范。

2026-04-177

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 的现有章程模板.
- 识别每个 [ALL_CAPS_IDENTIFIER] 形式的占位符标记. 重要提示: 用户可能需要比模板中使用的原则更少或更多. 如果指定了数字, 请遵循该数字 - 遵循通用模板. 你将相应地更新文档.
为占位符收集/推导值:
- 如果用户输入(对话)提供了值, 则使用它.
- 否则从现有仓库上下文推断(README, 文档, 先前的章程版本(如果嵌入)).
- 对于治理日期: RATIFICATION_DATE 是原始采用日期(如果未知, 请询问或标记 TODO), LAST_AMENDED_DATE 是今天(如果进行了更改), 否则保留之前的日期.
- CONSTITUTION_VERSION 必须根据语义版本控制规则递增:
  - MAJOR(主版本): 向后不兼容的治理/原则删除或重新定义.
  - MINOR(次版本): 新原则/部分添加或实质性扩展指导.
  - PATCH(补丁版本): 澄清, 措辞, 拼写错误修复, 非语义优化.
- 如果版本递增类型不明确, 请在最终确定之前提出理由.
起草更新后的章程内容:
- 用具体文本替换每个占位符(除了项目选择尚未定义的故意保留的模板槽位外, 不留下括号标记——明确说明任何保留的槽位).
- 保留标题层次结构, 一旦替换可以删除注释, 除非它们仍然提供澄清指导.
- 确保每个原则部分: 简洁的名称行, 捕获不可协商规则的段落(或项目符号列表), 如果不明显则提供明确的理由.
- 确保治理部分列出修改程序, 版本控制策略和合规审查期望.
一致性传播检查清单(将先前的检查清单转换为主动验证):
- 读取 .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 或代理特定指导文件(如果存在)). 更新对已更改原则的引用.
生成同步影响报告(在更新后作为 HTML 注释前置到章程文件顶部):
- 版本更改: 旧版本 → 新版本
- 修改的原则列表(如果重命名, 则为旧标题 → 新标题)
- 添加的部分
- 删除的部分
- 需要更新的模板(✅ 已更新 / ⚠ 待处理)及文件路径
- 如果有任何占位符故意延迟, 则提供后续 TODO.
最终输出前的验证:
- 没有剩余的未解释的括号标记.
- 版本行与报告匹配.
- 日期采用 ISO 格式 YYYY-MM-DD.
- 原则是声明性的, 可测试的, 并且没有模糊语言("should" → 在适当的地方用 MUST/SHOULD 理由替换).
将完成的章程写回 .specify/memory/constitution.md(覆盖).
向用户输出最终摘要, 包括:
- 新版本和递增理由.
- 任何标记为手动后续处理的文件.
- 建议的提交消息(例如 docs: amend constitution to vX.Y.Z (principle additions + governance update)).

格式和样式要求:

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

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

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

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