Runs on Claude Code, Codex and Copilot CLI

Adapters for Python, TypeScript and Go

Make agents prove their work.

3Powers is a complete harness for AI-generated software. Set the rules of your project once in a constitution, describe what you want, and coding agents specify, plan, build and test it for you — checked at every step by deterministic gates the agents cannot grade. You approve the spec and accept, revise or reject the result. That is your whole job.

$uv tool install 3powers

Walk a real run → How verification works →

Full lifecycle, one command — intent in, merge-ready branch out Your constitution steers every agent, on every run Every verdict signed in a tamper-evident ledger

3pwr run — ticket JIRA-SUP-4417

What you get

Your job becomes the guidance. The delivery is automatic.

Every team building with AI today rebuilds the same scaffolding for every project: the prompts, the rules, the review steps, the gates somebody hopefully remembers to add. It costs days per project, and no two setups match. 3Powers replaces that with one standard harness you install once and reuse everywhere.

You describe your project in a constitution — architecture, code patterns, naming rules, dependency policy, testing conventions, the security lines agents may never cross, the business rules that matter to you. Every stage of every run loads it as the law of the project, and you can extend it with external sources: MCP servers, reference docs, your own data. The shipped template walks you through exactly what to fill in.

From then on your day looks like this: write what you want, approve the specification, and take delivery of a verified, merge-ready branch. You accept it, revise it, or reject it. The building happened without you, and the checks that make the result trustworthy are deterministic software — not a model's opinion of its own work.

1Set your constitution
2Describe the change
3Approve the spec
4Accept, revise, or reject

Where you run more than one model family, 3Powers pins the judge to a different family than the coder. Recommended, but the trust does not hang on it: the sealed spec, the gates and the signed ledger work the same if you only ever use one provider.

How it works

What a run hands you

3Powers drives the whole lifecycle at high autonomy. These are the three things you hold at the end — none of which the agents graded themselves.

The tier suite — the same verdict, whichever model wrote the code gates green 0/11

01✓formatthe tree is formatted to your project's rules
02✓lintno suppressed rules, no inline disables
03✓typesthe type checker is clean, not silenced
04✓spec_integritythe sealed spec has not moved underneath the work
05✓teststhe oracle suite and the coder's own tests pass
06✓diff_coveragethe change is covered to the tier's threshold
07✓saststatic analysis over the whole tree
08✓dependency_scanno dependency carries a known vulnerability
09✓secret_scannothing credential-shaped got committed
10✓gate_gamingno gate was weakened to make it pass
11✓spec_conformanceevery requirement is actually implemented

Work-kind gates are added per change, and mutation joins at High-risk. Gold marks the four gates a self-graded harness has no equivalent for. A gate is never satisfied by weakening it.

01 · The answer key

A test suite that never saw the code

Written from your approved spec alone, one test per requirement, before any implementation exists. After build, this suite decides whether the spec was implemented completely. At High-risk the oracle runs in a sanitized workspace where the implementation is physically absent.

- Coverage: 6/6 acceptance criteria have ≥1 named oracle test
- Independence: confirmed read only the sealed spec — no implementation, plan, tasks or contracts

02 · The verdict

One readable answer: does this ship or not

The tier suite above runs cheapest-check-first and produces a single normalized verdict — every failure named and locatable, the whole tree judged, not just your diff. When it goes red, a bounded auto-fix loop hands the failure back to the coder with one rule: fix the code, never the check.

verdict FAIL id=006 tier=Standard adapter=typescript
✗ dependency_scan · osv-scanner
GHSA-6g55-p6wh-862q in postcss

03 · The evidence

A signed record you can verify offline

Every verdict and sign-off is hash-chained and Ed25519-signed in an append-only ledger, reconstructable from the repository alone. A local advance gate refuses to ship without green gates and a named human sign-off. No CI/CD platform required, nothing to phone home to.

$ 3pwr verify
ledger OK — 76 entries, chain and signatures intact

Proof, from one real run

A four-sentence ticket in, a merge-ready branch out

Not a mock-up. One actual 3pwr run on a small Next.js app — scroll to walk it, or drive the replay yourself.

3pwr run — ticket JIRA-SUP-4417

Stage 00the input

One ticket, one command

Four sentences somebody wrote in thirty seconds, with an EARS block that quietly contradicts itself. No prompt engineering, no scaffolding, no orchestration script — 3pwr run --file and that is the whole invocation.

Stage 01discovery

Research before anyone writes code

Discovery analyses the current state: it reads the codebase, works out what the ticket actually touches, and collects what is still open. Here it flagged that the ticket's “added or removed” would tempt an agent into building a delete feature nobody asked for. Findings, open questions and candidate non-goals are handed to the spec stage.

Stage 02spec · human gate 1

The single source of truth — and where you invest your time

From your intent, this stage writes the specification and challenges every ambiguity it finds. “A large number.” “Next to.” “Read as part of the heading.” Each became something a test can check. This is the one place to spend real attention: approve, reject, or revise. Once you approve, the spec is sealed — if that text moves underneath the work, spec_integrity fails the run.

Stage 03oracle

Every requirement gets a test that fails today

The oracle writes at least one acceptance test per requirement of the sealed spec — 344 lines here — in its own session, before any implementation exists. All of them fail, because there is nothing to pass yet. After build, this suite is what decides whether the spec was implemented completely.

Stage 04plan

The how, then the phases

Planning turns the spec into a high-level technical plan and challenges it with its own clarification pass before anything depends on it. From that plan comes the implementation plan: the detailed phases and tasks the build agents will execute, each phase with a declared file scope.

Stage 05build

Fresh sessions, parallel where the plan allows

Build works through the implementation plan phase by phase — one fresh agent session and one commit per phase, phases distributed to subagents in parallel when their file scopes do not overlap. The coder writes its own tests too. What it may never do is write, edit or delete the oracle tests it is graded against.

Stage 06verify · the verdict

Red — on something the feature never touched

Verify runs everything: the oracle suite, the coder's tests, and the deterministic gates of the tier suite. Here it failed the run on a vulnerable transitive dependency, nowhere near the two files that changed. The auto-fix loop handed it back with one rule: fix the code, never the check. The agent upgraded the dependency.

Stage 07–08sign-off · ship

Green, signed, waiting for you

When verification is clean the run stops and waits. You read one normalized verdict file — do I accept this?, not can I reconstruct what happened? — and approve, reject, or revise. On approval, every change is already tracked in the signed ledger (entry 75 on this run), the tree is clean, and the branch is ready to push.

Read the annotated walkthrough →

The lifecycle

Nine stages. You appear at two of them.

In auto mode everything between the two human gates runs without prompting you — driven by 3Powers' own native executive plus your coding-agent integration, and judged by the deterministic gates.

1Discovery

2Spec

§approve the spec

3Oracle

4Plan

5Build

6Verify

7Review

§sign-off

8Ship

9Observe

a production lesson returns as a new run — never an ad-hoc patch

Legislative

The spec decides

Versioned, testable requirements with explicit non-goals and a risk tier. Approved by a human, then sealed.

Executive

The agents build

Any model family, any supported language, inside a declared file scope. Native, provider-agnostic; Git is the substrate.

Judiciary

Something else judges

The oracle, the deterministic gates, and your sign-off — none of which the branch that wrote the code controls.

“The idea underneath every page is that no branch checks itself.”
— The AI-First SDD Playbook

Risk tiers

One knob sets every threshold

Rigour costs time, so you spend it where the risk is. The tier is the single source of every threshold — coverage, mutation score, model diversity, required test layers, and which gates run at all.

Cosmetic

docs · CLI polish

Lint and types, no ceremony. For changes that cannot break behaviour.

diff coverage —

mutation score —

model diversity not required

test layers none required

formatlinttypesspec_integrity

Standard

default · most work

Important to correctness; failures visible and recoverable. This is what most changes get.

diff coverage ≥ 80%

mutation score opt-in

model diversity required

test layers unit

formatlinttypesspec_integrity testsdiff_coveragesastdependency_scansecret_scangate_gamingspec_conformance

High-risk

this is the trust

The strictest bar: diversity and mutation required, oracle isolation proved from the ledger. 3Powers holds its own trust-spine code here.

diff coverage ≥ 95%

mutation score ≥ 70%

model diversity required

test layers unit · integration · e2e

formatlinttypesspec_integritytestsdiff_coveragemutationsastdependency_scansecret_scangate_gamingspec_conformance

If a change needs a higher bar, you raise its tier. You never lower the gate.

The problem

A passing build only proves the model agreed with itself

Hand a capable agent a feature and it will write the spec, the code, the tests, and the review. They all pass, because they all came from the same mind. Nothing independent ever checked the work.

So the artefact you get is a green checkmark with no evidence behind it. The scarce thing is no longer the code — it is confidence that the code does what was intended, and confidence is exactly what a self-graded build cannot produce.

spec code tests review

all from the same mind

No independent check

The field manual

The Playbook explains the why. 3Powers is the how, enforced.

FIELD MANUALSEASON 1 · V1.0 ◆ SPEC‑DRIVEN DEVELOPMENT The AI‑First
SDD Playbook LEGISLATIVE·EXECUTIVE·JUDICIARY Spec-Driven Development for the Agentic SDLC. A Field Manual. CARLO VERZERI Season 1, v1.0 · Last revised June 2026

Why validation collapses — what happens when one model writes and grades the same change, and what independence has to mean to fix it.
The judiciary gates — tests against the spec, mutation and static analysis, dependency and secret scanning, spec conformance, build provenance.
The eight-stage cycle — one feature followed end to end, from discovery to observe and operate.
Off the happy path — when to deviate, the failure catalogue, and adopting this in a codebase that already exists.

Open the Playbook Read the concepts

Get started

Three commands, then two decisions

Works on a new or existing project. The deterministic half — gates, ledger, enforcement — is pure 3pwr and needs no agent at all.

Install the engine
Published on PyPI as 3powers; the command it installs is 3pwr. Needs uv.
Initialise your project
Guided onboarding: language, where the signing key lives (always outside the repo), and whether autonomous mode is your default.
Describe what you want built
The lifecycle runs end to end, streams a live stage tracker, and stops only at the two human gates.