Install the engineering discipline, not just the prompt.
Programming agents generate code. Engineering agents generate evidence.
D³ is a small SDK for engineering agents — Codex, Claude Code, Pi, Kimi Code, and OpenCode — that makes them earn architectural decisions with observable evidence: turning a build request into an architectural question, a refutable slice, and an explicit evidence contract, before implementation momentum hardens an assumption into architecture.
What it distributes is not instructions. It is roles, contracts, and a protocol — seven stations,
each producing a typed artifact the next one consumes. The skills are one implementation of the
stations; contracts/ is what any implementation has to satisfy.
Native skills for Codex, Claude Code, Pi, Kimi Code, and OpenCode · Prompt fallback for any agent · Status: hypothesis, designed to be refuted
It complements Domain-Driven Design, TDD, SDD, and ADRs. It governs the step before them:
Question → Hypothesis → Slice → Adversarial review → Evidence → Doctrine → Next question
They split by how you already work, not by feature count.
curl -fsSL https://raw.githubusercontent.com/governed-software/doctrine-driven-development/main/install.sh | bashgoverned-discovery · governed-review · governed-close
The loop, compressed: frame the question, break the claims, settle what was proved. Its entire job is to change your first move. Start here even if you are experienced — it is the cheapest way to find out whether the discipline does anything for you.
curl -fsSL https://raw.githubusercontent.com/governed-software/doctrine-driven-development/main/install.sh | bash -s -- --proStarter plus governed-scout · governed-sdd · governed-plan · governed-slice · governed-adr
The full station chain, for someone who already thinks this way and wants the agent to work the process instead of teaching it.
Scout → Architect → Planner → Builder → Reviewer → Recorder
scout sdd plan slice review close → adr
Each station consumes one named artifact and produces the next station's input — and refuses to do the
next station's job. That contract is what makes this a pipeline rather than eight prompts sharing a
prefix; it lives in pipeline.md.
Professional includes Starter. governed-discovery stays on as the one-minute compression of
Scout + Architect, for when the full chain would be ceremony.
Install the repository as a native Pi package:
pi install git:github.com/governed-software/doctrine-driven-developmentStart a new Pi session, then try:
/skill:governed-discovery add offline sync to our app.
Pi can also invoke the skill implicitly when a build request matches its description.
Note on tiers for Pi. The native package registers the whole
skills/directory, sopi install git:…gives you all eight stations regardless of tier. If you want Starter only, use the installer instead:install.sh --pi.
Install the native skills (add --pro for the full station chain):
curl -fsSL https://raw.githubusercontent.com/governed-software/doctrine-driven-development/main/install.sh | bash -s -- --codexStart a new Codex session, then try:
Use $governed-discovery to frame this before code: add offline sync to our app.
Codex can also invoke the skill implicitly when a build request matches its description.
curl -fsSL https://raw.githubusercontent.com/governed-software/doctrine-driven-development/main/install.sh | bashStart a new Claude Code session and ask it to build or add a feature. governed-discovery will frame
the request before implementation.
Install the native skills (add --pro for the full station chain):
curl -fsSL https://raw.githubusercontent.com/governed-software/doctrine-driven-development/main/install.sh | bash -s -- --kimiStart a new Kimi Code session, then try:
/skill:governed-discovery add offline sync to our app.
Kimi Code can also invoke the skill implicitly when a build request matches its description.
Install the native skills (add --pro for the full station chain):
curl -fsSL https://raw.githubusercontent.com/governed-software/doctrine-driven-development/main/install.sh | bash -s -- --opencodeStart a new OpenCode session, then try:
add offline sync to our app.
OpenCode loads skills on-demand via its native skill tool and invokes them implicitly when a
build request matches the skill description. You can also call it explicitly:
use the governed-discovery skill to frame this build request before proposing an implementation.
That is the complete runtime setup. Each skill has one canonical, portable SKILL.md; Codex adds its
own UI metadata sidecar. There is no daemon, API key, runtime dependency, or project configuration.
Instead of jumping from request to implementation, governed-discovery produces a compact frame. The
two lines that bracket it are the point — they are written in the first person because what moves is the
engineer's belief, not the agent's output:
Before: the first thing I thought I should build was …
Architectural question What answer would change the build order?
Overclaim to avoid What would the current evidence not support?
Refuting slice What is the smallest slice that could prove us wrong?
Evidence contract What observable result would count?
Deferred on purpose What must not become architecture yet?
After: is the original first move still first?
If the first move changes, the framing found a load-bearing uncertainty. If it never changes, say so: the run produced curiosity, not architecture.
| Skill | Use it when… | Contract |
|---|---|---|
governed-discovery |
starting a build / implement / add request | frame the architectural question and the smallest slice that could refute it |
governed-review |
reviewing a change, PR, document, or claim | try to break load-bearing claims against their actual artifacts |
governed-close |
a slice looks done | state exactly what the evidence proved, what it did not, and what stays deferred |
A typical Starter workflow:
governed-discovery → implement the refuting slice → governed-review → governed-close
Every station is a role that refuses the next role's job. Full contract in
pipeline.md.
| Role | Consumes | Produces | Implemented by |
|---|---|---|---|
| Scout | a question or a hunch | ScoutReport — cited facts, named unknowns, contradictions. Never a recommendation. |
governed-scout |
| Architect | ScoutReport |
ArchitectureQuestion — only what survives the reorder test, plus what was cut |
governed-sdd |
| Planner | ArchitectureQuestion |
ExecutionPlan of SliceSpecs, ordered by blast radius |
governed-plan |
| Builder | SliceSpec |
EvidenceBundle — raw, reproducible, plus the scope ledger |
governed-slice |
| Reviewer | any claim + its artifact | ReviewVerdict — confirmed · overstated · unproven · refuted |
governed-review |
| Recorder | EvidenceBundle + its SliceSpec |
Settlement — proved, not proved, next question, ADR candidate |
governed-close |
| Recorder | a Settlement with a candidate |
DecisionRecord — today we proved that…, with the observation that would kill it |
governed-adr |
The role is the unit, not the skill name. A skill is one implementation of a station; swap it and the chain still holds, as long as the artifact still satisfies its contract.
You do not owe the chain all seven stations. Enter wherever the artifact you hold matches a station's Consumes column, and leave as soon as the question is answered. The one rule that never relaxes: do not skip a station by having another one quietly do its job.
Every station writes to a file in the repository it governs, under .governance/ — because a handoff
into a conversation is not a handoff. Starter keeps four files (constitution.md, discovery.md,
questions.md, decision-log.md); Professional adds findings/, slices/, reviews/, and
decisions/. Markdown, sequential IDs, nothing deleted. Layout and rules in
pipeline.md — including why the compiled form stays deferred.
| Agent | Support | Install / use |
|---|---|---|
| Codex | Native skill discovery and UI metadata | install.sh --codex, then $governed-discovery or implicit invocation |
| Claude Code | Native skill discovery | install.sh or install.sh --claude |
| Pi | Native package and skill discovery | pi install git:github.com/governed-software/doctrine-driven-development or install.sh --pi, then /skill:governed-discovery or implicit invocation |
| Kimi Code | Native skill discovery | install.sh --kimi, then /skill:governed-discovery or implicit invocation |
| OpenCode | Native skill discovery via skill tool |
install.sh --opencode, then implicit invocation or use the governed-discovery skill |
| Gemini / Cursor | Portable prompt | paste the no-install prompt below |
| Any other agent | Portable prompt | same instructions; no adapter required |
curl -fsSL https://raw.githubusercontent.com/governed-software/doctrine-driven-development/main/install.sh | bash -s -- --all--all installs all five variants. The agent flag and the distribution flag combine in either order —
--all --pro, --codex --pro, --pro --kimi. Codex installs to $CODEX_HOME/skills/, or
~/.codex/skills/ when CODEX_HOME is unset. Claude Code installs to ~/.claude/skills/. Pi installs
to $PI_CODING_AGENT_DIR/skills/, or ~/.pi/agent/skills/ when the variable is unset; set
PI_SKILLS_DIR to override only the installer destination. Kimi Code installs to
$KIMI_CODE_HOME/skills/, or ~/.kimi-code/skills/ when KIMI_CODE_HOME is unset; set
KIMI_SKILLS_DIR to override only the installer destination. OpenCode installs to
$OPENCODE_HOME/skills/, or ~/.config/opencode/skills/ when OPENCODE_HOME is unset; set
OPENCODE_SKILLS_DIR to override only the installer destination.
This keeps the operation fully local and easy to inspect:
git clone https://github.com/governed-software/doctrine-driven-development.git
cd doctrine-driven-development
# Pi: register this clone as a local package; Pi discovers skills/ automatically.
pi install "$PWD"
# Or install a copied variant for any supported agent. When run from the
# clone, the installer reads these local files instead of downloading them.
./install.sh --pi # use --claude, --codex, --kimi, --opencode, or --all as needed
./install.sh --pi --pro # add --pro for the full station chainStart a new agent session after installing so it reloads the skill catalog.
No install? Use the portable prompt
Paste this into any agent, then give it a build request:
Before writing any code for a build/implement/add request, frame it first (D³ governed-discovery):
1. What architectural question are we really answering? Architectural means its answer changes the BUILD ORDER; if it would not reorder anything, keep digging.
2. What claim would be too big for the evidence we have?
3. What is the minimal slice that could REFUTE the idea? Not ship the feature — the smallest thing that, if it fails, proves the framing wrong.
4. What observable result would count as evidence? A red/green, a number, or a reproducible diff; "it works" does not count.
5. What is explicitly out of scope, and what decision are we deferring because there is no evidence yet?
Then ask: "Is my first move still the first?" If it changed, proceed to the reordered slice. Do not write code until this frame exists.
Before running governed-discovery, note the implementation you were about to start. After the
frame, ask:
Is it still the first thing you would build?
- No — the Discovery changed the decision order; the hypothesis survives this run.
- Yes, always — it produced curiosity, not architecture; improve or reject the framing.
Refusing to manufacture a win is part of the discipline. A failed hypothesis is useful evidence.
Why this exists
Most methodologies begin at planning. D³ begins earlier: it protects a project from making its first important decision too soon. The costliest decisions are often correct implementations of the wrong question.
- Discovery asks questions, not solutions. It should expose relevant uncertainty, not close it prematurely.
- A question is architectural only when its answer changes the order of construction. Anything else may be interesting, but it is not load-bearing.
- An ADR is not an initial decision. It is the crystallization of what a slice proved: today we proved that…, never we think that….
The skills ship as hypotheses, not settled tooling. The central adoption claim, H-001, remains
unproven and refutable; see hypotheses.md. Every datapoint so far is internal. If
the skill never changes anyone's first move, the skill is refuted — not the doctrine.
- It never lets implementation effort stand in for evidence.
- It never claims more than a slice proved.
- It never lets memory or conversation become law; only the written record is authoritative.
- It never promotes a deferred decision before evidence earns it.
constitution.md— the principles; the canonical law.pipeline.md— the stations, the refusals, and where artifacts land; authority for the chain.contracts/— the typed artifacts (ScoutReport→DecisionRecord); authority for their shape.hypotheses.md— H-001, H-002, and exactly how each dies.questions.md— D³'s own Discovery.decision-log.md— evidence-backed and deliberately deferred decisions.lab-log.md— experiments and harvested datapoints.skills/— the executable stations.install.sh— installer for Codex, Claude Code, Pi, Kimi Code, and OpenCode.
D³ emerged independently across three unrelated stacks — Milpa, OverlayKit, and DOM Protocol. Same discipline, three languages; that is why it lives in a company-neutral home instead of one implementation.
Apache-2.0 · © Rodrigo Vicente — TeamX Agency · governed.software