sdd-constitution

项目章程（openspec/project.md）

章程是一组简短、稳定的规则，仓库中的每项变更都必须遵守——也就是 AI 在编写规范或代码时不得违反的“内部规则”。OpenSpec 会读取 openspec/project.md；sdd-feature-flow 的 Analyze 阶段会标记任何与章程冲突的要求，并在缺少章程时给出提示。

适用场景

• 采用 SDD 的仓库尚无 openspec/project.md（Analyze 阶段会提示这一点）。
• 团队约定、技术栈或约束发生变化，导致章程内容过时。

流程

1. 先了解，不要发号施令。 提出原则之前，先阅读仓库，判断哪些情况已经存在：README、CONTRIBUTING、现有的 CLAUDE.md/AGENTS.md、lint/format 配置、测试设置、包清单、CI，以及几个有代表性的模块。记录实际使用的技术栈、测试/lint 命令、分支流程和明显的约定。
2. 起草 openspec/project.md，包含以下章节（每节都要简洁——写原则，不写散文）：
   • 用途——用一段话说明项目是什么。
   • 技术栈与工具——语言、框架、包管理器、测试/lint 命令。
   • 不可妥协的原则——AI 绝不能违反的规则。例如：“注释说明原因，而非内容”、“不得通过环境变量启用功能标志”、“每次提交都要签名”、“环境分支之间不得跨分支合并”。这些原则应来自仓库和用户，而不是通用清单。
   • 约定——命名、错误处理、十进制/精度规则、资源标识符、目录结构等——所有对确保本仓库正确性至关重要的内容。
   • 分支与发布流程——例如 feature → develop → testing → main；PR 的默认目标分支。
   • 完成定义——测试通过、文档已更新、规范已归档等。
3. 向用户确认任何从仓库中推断出但无法核实的内容——错误的章程比没有章程更糟。
4. 验证：openspec validate --strict 仍能通过；SDD 流程会自动引用该文件（无需额外配置）。

规则

• 简短且不可妥协，胜过冗长而空泛。无法落实的条目就删掉。
• 每项原则都必须以仓库内容或用户明确陈述为依据——绝不凭空编造内部规则。
• 此技能只编写 openspec/project.md（并提出问题）。不编写生产代码。