mcpField
S
sdd-constitution

sdd-constitution

github.com/alejandro-cedeno-10Development0129 installsUpdated 17w ago
Repository

About sdd-constitution

sdd-constitution is an agent skill for drafting or updating a repository's openspec/project.md with stable project rules. It grounds principles in repository evidence and user confirmation, and validates the file with OpenSpec.

Key features

  1. 01Inspects repository conventions
  2. 02Drafts openspec/project.md
  3. 03Defines stack and project rules
  4. 04Confirms unverifiable assumptions
  5. 05Validates with OpenSpec

Use cases

  1. 01Adding a constitution to an SDD repository
  2. 02Updating project rules after conventions change

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/alejandro-cedeno-10/agentic-sdd-kit --skill sdd-constitution

After installing, type/sdd-constitutionin Claude Code to confirm it loaded.

Details

From the project README

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

  1. 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.
  2. 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.
  3. Confirm with the user anything you inferred but couldn't verify from the repo — a constitution that's wrong is worse than none.
  4. 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.

Comments

Markdown supported