Back to Imewlconverter

Speckit.Constitution

.codebuddy/commands/speckit.constitution.md

3.3.14.4 KB
Original Source

用户输入

text
$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.mddocs/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 文件.