governance-constitution
Create, amend, or check a project's governing "constitution" - the small set of non-negotiable engineering principles that every agent run (Claude Code and GitHub Copilot) should honour. Use when the
SKILL.md.claude/skills/governance-constitution/SKILL.md
GitHubConstitution
Owned by the Lead persona (custodian of the contract and graph integrity). Invoked as /governance-constitution.
Create and maintain a project's constitution: a short list of non-negotiable principles that govern how the team and its AI tools (Claude Code + Copilot) build software. The constitution is the spine of the AI-SDLC contract. It works only if it is small, always-loaded, and every clause is enforceable - a long prose document that no tool loads and no check enforces is worse than nothing (it creates false confidence).
Where it lives and how it loads (do not get this wrong)
The contract is split into an always-loaded core and on-demand detail. This split is load-bearing for token cost, so respect it:
| Part | Lives in | Load policy |
|---|---|---|
| Constitution core (clause statements only, aim <= ~12 clauses, one line each) | AGENTS.md (a ## Constitution section) |
Always-on, by design. Read natively by Copilot; by Claude via the root CLAUDE.md stub. Keep it tiny. |
| Full constitution (each clause's rationale, enforcement, history) | docs/constitution.md |
On demand. Read only when someone needs the detail. |
Why not import the full file into context? In Claude Code, @import is eager (it
loads at launch and does not save tokens), and Copilot cannot import at all. So the
core must physically sit in AGENTS.md, and the detail must stay a separate on-demand
file. Never @import docs/constitution.md or the ADRs into CLAUDE.md/AGENTS.md.
Claude reads CLAUDE.md, not AGENTS.md. So the root CLAUDE.md must contain
@AGENTS.md (an import line) so Claude picks up the core. On Windows use the import
line, not a symlink (symlinks need admin). Copilot reads AGENTS.md directly.
Modes
Detect which the user wants; ask if ambiguous.
- create - bootstrap a constitution for a repo that has none.
- amend - add, change, or supersede a clause in an existing constitution.
- check (read-only) - review proposed or recent changes against the constitution and report violations. No writes.
Clause format
Every clause is a testable, non-negotiable rule. In docs/constitution.md each clause carries:
### C<NN>: <short imperative statement>
- **Statement:** <the rule, one sentence, verifiable not vague>
- **Rationale:** <why this is non-negotiable here>
- **Enforcement:** <mechanism> - <status>
mechanism = CI gate | linter | hook | skill | code review (manual)
status = active | deferred (planned: <what + where, e.g. "ADO coverage gate">)
- **Added:** <YYYY-MM-DD> **Version:** <bump on change> **Supersedes:** none | C<NN>
The AGENTS.md core carries only the imperative statement line per clause (so the always-on cost stays minimal). Detail lives in docs/constitution.md.
The enforcement field is mandatory. A clause with no enforcement is the "constitution
as prose" anti-pattern. If the gate does not exist yet, record it as deferred (planned: ...)
so it is a tracked debt, not an aspiration. This is what lets the gate phase bolt on later.
Good clauses are concrete: "Test line coverage must be >= 80% on changed projects", "Every Bicep module reference pins an explicit version tag (no @latest)", "Load-bearing architectural decisions require an ADR in docs/adrs/ before merge". Avoid "write clean code" style non-clauses.
create workflow
- Seed from what exists, do not invent. Read the repo's current standards and lift the real, already-followed rules:
CLAUDE.md,AGENTS.md,.github/copilot-instructions.md,docs/conventions/*, anydocs/adrs/*. The constitution should ratify the team's actual non-negotiables, not impose new ones. - Interview for the gaps. Briefly confirm the candidate clauses with the user and ask what else is truly non-negotiable (security, coverage, naming, decision-recording, deployment safety). Keep pushing items that are "nice to have" out of the constitution and into conventions or docs.
- Draft both artefacts. Write
docs/constitution.md(full, every clause with rationale + enforcement) and the## Constitutioncore inAGENTS.md(statements only). Keep the core to ~12 clauses; if there are more, the extra ones probably belong in path-scoped conventions, not the constitution. - Wire the loaders.
- If
AGENTS.mddoes not exist, create it with: a short project-facts section, the## Constitutioncore, and a## Where the detail livespointer block (todocs/constitution.md,docs/adrs/, conventions). - Ensure the root
CLAUDE.mdmakes Claude readAGENTS.md(see "Handling an existing CLAUDE.md"). - Remove
.github/copilot-instructions.mdonly if its content has been folded intoAGENTS.md(Copilot readsAGENTS.md); otherwise leave it and note the overlap.
- If
- Confirm the diff before writing, then write. Report what loads always (the core) vs on demand.
amend workflow
- Read
docs/constitution.mdand theAGENTS.mdcore first (never blind-write). - Apply the change: add a new
C<NN>, modify an existing clause, or supersede one (mark the old clauseSuperseded by C<NN>, keep it indocs/constitution.mdfor history, remove it from theAGENTS.mdcore). - Bump the document version and append a one-line entry to a
## Historysection indocs/constitution.md(date, what changed, why). Git history is the backstop, but the explicit log helps reviewers. - Keep the
AGENTS.mdcore anddocs/constitution.mdin sync (statements identical). If the core grew past ~12 clauses, flag it and propose moving the weakest clause out. - Confirm the diff, then write.
Handling an existing CLAUDE.md (important)
Many repos already have a large CLAUDE.md (this is common). Never overwrite it with a one-line stub. Instead:
- Offer to migrate: move its durable, tool-neutral content into
AGENTS.md, then reduceCLAUDE.mdto@AGENTS.mdfollowed by any genuinely Claude-only notes. - If the user does not want to migrate now, leave
CLAUDE.mdas-is and add@AGENTS.mdat its top so Claude still loads the core. Note the duplication risk for later cleanup. Either way, surface the existing file and the proposed change before touching it.
Guardrails
- Police the core's size. The
AGENTS.mdcore is the only always-on cost for both tools. If it exceeds ~1 screen, move detail todocs/constitution.mdor to path-scoped conventions. - Confirm before writing any of
AGENTS.md,CLAUDE.md, ordocs/constitution.md. Show the diff. These files are load-bearing. - Respect repo doc rules. No source line numbers in any clause or doc (reference files by path + symbol). No em-dashes; use commas, colons, parentheses, or " - ". Match the repo's existing heading style.
- Verify clauses against reality. Do not write a clause the codebase already violates without flagging it - either the clause is wrong or there is debt to record. State which.
- Every clause names its enforcement. Deferred is allowed; absent is not.
Next steps
- If a new or amended clause needs a code or doc change to comply, run
/create-code-generation(Developer) or/create-upsert-documentation(Tech Writer). - If the clause came out of a specific architectural decision, record it with
/governance-author-adr(Architect) and backlink it via/governance-enrich-ticket. - A clause's enforcement (its gate) is wired in the deferred gate phase; until then it is upheld in review.