sdd-constitution

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Project constitution (openspec/project.md)

项目章程（openspec/project.md）

A constitution is the short, stable set of rules every change in this repo must respect — the "house rules" the AI must not violate when it authors specs or writes code. OpenSpec reads

openspec/project.md

; the

sdd-feature-flow

Analyze phase flags any requirement that contradicts it (and notes, as an advisory, when it's missing).

章程是本仓库中每一项变更都必须遵守的简短、稳定规则集——即AI在撰写规格说明或编写代码时不得违反的“内部规则”。OpenSpec会读取

openspec/project.md

文件；

sdd-feature-flow

的Analyze阶段会标记任何与之矛盾的需求（并在缺失时给出建议提示）。

When to use

使用时机

A repo adopting SDD has no
```
openspec/project.md
```
yet (the Analyze gate will advise this).
The team's conventions, stack, or constraints changed and the constitution is stale.

采用SDD的仓库尚未创建
```
openspec/project.md
```
文件时（Analyze环节会给出此建议）。
团队的约定、技术栈或约束条件发生变化，导致章程过时。

Procedure

操作步骤

Discover, don't dictate. Read the repo to infer what's already true before proposing principles:
```
README
```
,
```
CONTRIBUTING
```
, existing
```
CLAUDE.md
```
/
```
AGENTS.md
```
, lint/format config, test setup, package manifests, CI, and a few representative modules. Note the real stack, the test/lint commands, the branch flow, and any obvious conventions.
Draft
openspec/project.md
with these sections (keep each tight — principles, not prose):
- Purpose — one paragraph: what this project is.
- Tech stack & tooling — languages, frameworks, package manager, test/lint commands.
- Non-negotiable principles — the rules the AI must never break. Examples: "comment WHY not WHAT", "no feature flags via env vars", "sign every commit", "no cross-branch merges of environment branches". Draw these from the repo + the user, not from a generic list.
- Conventions — naming, error handling, decimal/precision rules, resource identifiers, directory layout — whatever is load-bearing for correctness in THIS repo.
- Branch & release flow — e.g.
```
feature → develop → testing → main
```
  ; PR target defaults.
- Definition of done — tests green, docs updated, spec archived, etc.
Confirm with the user anything you inferred but couldn't verify from the repo — a constitution that's wrong is worse than none.
Validate:
```
openspec validate --strict
```
still passes; the file is referenced by the SDD flow automatically (no wiring needed).

探索而非规定。在提出原则前，先读取仓库内容以推断现有规则：
```
README
```
、
```
CONTRIBUTING
```
、已有的
```
CLAUDE.md
```
/
```
AGENTS.md
```
、代码检查/格式化配置、测试设置、包清单、CI配置以及几个代表性模块。记录实际使用的技术栈、测试/代码检查命令、分支流程以及任何明显的约定。
起草
openspec/project.md
，包含以下部分（内容要简洁——只写原则，不写冗余描述）：
- 目的——一段文字：说明本项目的定位。
- 技术栈与工具——编程语言、框架、包管理器、测试/代码检查命令。
- 不可协商原则——AI绝对不能违反的规则。示例：“注释要说明原因而非内容”、“禁止通过环境变量使用功能标志”、“所有提交必须签名”、“环境分支之间禁止跨分支合并”。这些规则需来自仓库内容和用户需求，而非通用列表。
- 约定规范——命名规则、错误处理、小数/精度规则、资源标识符、目录结构——任何对本项目正确性至关重要的内容。
- 分支与发布流程——例如
```
feature → develop → testing → main
```
  ；PR默认目标分支。
- 完成定义——测试通过、文档更新、规格说明归档等。
与用户确认所有你推断但无法从仓库内容验证的内容——错误的章程比没有章程更糟糕。
验证：执行
```
openspec validate --strict
```
仍能通过；该文件会被SDD流程自动引用（无需额外配置）。

Rules

规则

Short and non-negotiable beats long and aspirational. If a line isn't enforceable, cut it.
Ground every principle in the repo or an explicit user statement — never invent house rules.
This skill writes ONLY
```
openspec/project.md
```
(and asks questions). No production code.

简短且不可协商的规则优于冗长且空泛的规则。如果某条规则无法强制执行，就删掉它。
每条原则都必须基于仓库内容或用户明确声明——切勿自行制定内部规则。
本技能仅负责编写
```
openspec/project.md
```
文件（以及提出问题）。不编写生产代码。