sdd-constitution

Original：🇺🇸 English

Translated

Author or update the project's constitution — openspec/project.md — the non-negotiable principles, conventions, and constraints the Spec-Driven Development flow must honor. Modeled on GitHub Spec-Kit's /constitution. Run once per repo when onboarding SDD, or whenever the team's principles change. The sdd-feature-flow Analyze gate checks every spec against it.

6installs

Sourcealejandro-cedeno-10/agentic-sdd-kit

Added on2026-07-07

NPX Install

npx skill4agent add alejandro-cedeno-10/agentic-sdd-kit sdd-constitution

SKILL.md Content

View Translation Comparison →

Project constitution (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).

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.

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).

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.