The previous posts in this series make an argument: the spec is the source of truth, a bug is a gap in it, and the pipeline keeps the two aligned. It holds — but an argument is all it was. Nothing in those posts stops a spec from drifting out of sync with the code the moment attention moves elsewhere; the discipline lived entirely on the page.

Govern is what moves it off the page. Specs need a place to live, the pipeline needs commands, and the lifecycle has to be enforced rather than aspirational. Govern is a thin, opinionated layer that turns spec-driven development from an argument into a workflow you can actually run.

What govern is

Govern is an open-source set of conventions, templates, and slash commands for AI coding agents. Nothing it provides ends up in your running product — it doesn’t compile into your application or ship with what you build. It’s a layer that lives in your repo and structures the work your coding agent does to produce code.

The pieces:

  • An entry point. AGENTS.md is the file the agent reads first — the project’s tech stack, commands, structure, and conventions, plus a pointer to the constitution. It’s the committed home for durable, project-specific rules, so they accumulate here as you work. (For Claude Code, CLAUDE.md imports it alongside the constitution.)
  • A constitution. constitution.md defines the pipeline (spec → plan → implement), the spec lifecycle (draft → clarified → planned → in-progress → done), the three artifact tiers (rules, specs, scenarios), and the rules every artifact must follow.
  • Rule sets. First-class artifact files for cross-cutting concerns. Govern ships rule files for security (backend and frontend), performance, accessibility, API design, and configuration, all written with enforceable RFC 2119 rules; the same format extends to any cross-cutting concern you want to add — observability, audit and compliance, and so on.
  • Templates. Markdown skeletons for specs, plans, tasks, data models, research notes, and scenarios, plus the project-level files (system.md, errors.md, events.md, inbox.md). Every artifact starts from a template, so the format stays consistent across the repo and across projects.
  • Slash commands. A full set of verb-named, session-aware commands that drive the pipeline, elaborate specs, and absorb existing reality during brownfield adoption.
  • A bootstrap command. /govern <project-name> scaffolds the whole thing into an existing repository.

How it gets installed

One command, in a project that already has an AI coding agent configured:

curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/stonean/govern/main/install.sh | sh

The installer detects your agent — Claude Code, Auggie, or Antigravity — and drops the /govern bootstrap command in the right place. (Name the agent explicitly if you’d rather: … | sh -s -- auggie.) Then run /govern <project-name> from inside the agent. The command fetches the constitution, the rule files, the templates, and the operational slash commands; resolves placeholders; writes a specs/ directory; and reports what changed. Both steps are idempotent — re-run either one any time to pull the latest files; it picks up what’s new and leaves the rest alone.

The three tiers

Govern recognizes three artifact tiers, ordered by scope:

  • Rules — cross-cutting requirements that apply across many features. Security controls, performance budgets, observability commitments, accessibility minimums. Rule files live under specs/rules/ and are cited by ID from the feature specs that depend on them.
  • Specs — feature-wide requirements. One feature’s behavior, acceptance criteria, and constraints in specs/{NNN-feature}/spec.md.
  • Scenarios — situational requirements. A specific condition with concrete behavior in specs/{NNN-feature}/scenarios/{slug}.md, attached to the spec it elaborates.

Bugs route to the tier that matches the scope of the gap. A perf bug across every endpoint promotes to a rule. A perf bug specific to one feature becomes an acceptance criterion on that spec. A perf bug that only manifests under a specific concurrency condition becomes a scenario.

The pipeline you run

For a new feature, the loop is:

/specify {feature description}    → drafts spec.md from template
/clarify                          → resolves open questions, advances to clarified
/plan                             → drafts plan.md and tasks.md, advances to planned
/analyze                          → audits the artifacts against each other before code is written
/implement                        → works through tasks, advances to in-progress
/review                           → audits the code against the rules; gates the move to done

Each command produces an artifact the next one consumes, and the spec carries a status as it advances — so a glance at specs/ tells you which features are designed, which are in flight, and which are done.

Two of those steps audit rather than build. /analyze isn’t a gate; it’s a safety check you can run at any point, surfacing gaps like missing acceptance criteria, unresolved open questions, rule citations that don’t resolve, or drift between artifacts. /review is the gate that matters: it audits the written code against the rule files and holds the spec out of done until any blocking violation is fixed or explicitly waived.

/ask handles elaboration mid-pipeline. It adds either an open question or a scenario to the targeted spec and owns the lifecycle back-edges — a new question reopens the spec to draft, a new scenario reopens a done spec to in-progress.

Brownfield adoption gets three commands of its own. /specify takes a sparse description and skeletons a spec from an existing feature, /log drops a raw item into specs/inbox.md, and /groom walks the inbox, routing each item through the decision tree to the right tier.

What it produces

After a few features, an adopting project’s repo looks like this:

specs/
  system.md                 ← architecture, shared conventions
  errors.md
  events.md
  inbox.md                  ← raw items awaiting grooming
  rules/
    security-backend.md     ← rule file, cited by ID from feature specs
    security-frontend.md
    performance-frontend.md
    ...
  templates/                ← spec / plan / tasks / scenario skeletons
  001-user-auth/
    spec.md
    plan.md
    tasks.md
    scenarios/
      token-expiry.md
  002-checkout/
    spec.md
    plan.md
    tasks.md
constitution.md
AGENTS.md
.claude/commands/govern.md
.claude/commands/my-project/...   ← the operational slash commands

The artifacts are version-controlled alongside the code they describe. A reviewer sees the spec, the plan, and the implementation in the same diff. A new contributor reads the specs and understands the system without asking. An AI agent given a task reads the spec and the cited rules, and produces code that satisfies them — no guessing, no drift.

Why this matters

The methodology by itself is an argument: the spec should be the source of truth, bugs are gaps in that source of truth, and the pipeline forces the artifacts to stay aligned with the code. All true. None of it is enforceable without scaffolding.

Govern is that scaffolding. The pipeline is no longer a set of slides — it is a set of commands. The spec lifecycle is no longer a convention — it is a status field the commands check. The bug decision tree is no longer a flowchart — it is /ask writing a scenario, /groom routing an inbox item, or a rule promoted into the rule file at the right tier.

There are other tools in this space and there will be more. Govern’s bet is that a thin, opinionated layer — markdown templates, a constitution, RFC 2119 rules, a handful of slash commands — gets out of the way better than a heavier framework would. The artifacts are plain files in a git repo. The pipeline is plain prose in a markdown document. Nothing about the system is opaque.

Where this series goes next

The next posts walk through govern in use — first a feature end-to-end from /specify through /implement, then the bug workflow with the actual artifacts at each tier. From here on, every post in this series uses govern as the working example, because the methodology is sharpest when you can see what it produces.

Govern is open source and lives at github.com/stonean/govern. The README has install instructions, the command reference, and links to the constitution and the rule files. Issues and pull requests welcome.