用途：为采用规范驱动开发（SDD）的仓库创建或更新 openspec/project.md，即“项目宪法”——一套每个变更都必须遵守的简短稳定规则，AI 在编写规范或代码时不得违反。OpenSpec 会读取该文件，sdd-feature-flow 的 Analyze 阶段会标记与宪法冲突的需求，并在文件缺失时给出提示（advisory）。
适用时机：仓库刚引入 SDD、尚无 openspec/project.md（Analyze 关卡会建议创建）；或团队约定、技术栈、约束已变化，宪法过期。
操作流程：先发现而非臆断。阅读 README、CONTRIBUTING、现有 CLAUDE.md/AGENTS.md、lint/format 配置、测试设置、包清单、CI 及若干代表性模块，确认真实技术栈、测试与 lint 命令、分支流程和明显约定。随后起草 openspec/project.md，含以下小节（每节保持精炼）：Purpose（一段话说明项目是什么）；Tech stack & tooling（语言、框架、包管理器、测试/lint 命令）；Non-negotiable principles（AI 绝不能破坏的规则）；Conventions（命名、错误处理、精度/小数规则、资源标识、目录布局等对本仓库正确性至关重要的内容）；Branch & release flow（如 feature → develop → testing → main，PR 默认目标）；Definition of done（测试通过、文档更新、规范归档等）。对推断但无法从仓库验证的内容须与用户确认——错误的宪法比没有更糟。最后验证：openspec validate --strict 仍通过；该文件会被 SDD 流程自动引用，无需额外接线。
规则与限制：短而不可协商优于长而空泛，无法执行的条款应删除；每条原则都必须有仓库依据或用户明确说明，不得编造内部规则；本技能只写入 openspec/project.md 并提出问题，不产出生产代码。收费、价格、平台等事实资料未提供。