Commission documentation

You will be able to find the one page you need in a single hop, and know before you open it whether it teaches, specifies, or explains.

Commission is the execution layer for software delivery. It holds the task graph, the rules for who may work on what, and the context each piece of work needs — and it hands them to whoever is doing the work, human or agent, in one read. Work is claimed atomically, so many agents can run in parallel without collisions. Completion is a predicate, not a status field: done is refused until acceptance criteria are ticked and the evidence a task’s gate requires is attached, and the refusal names the exact command that fixes it. Everything is derived from one truth — boards, “what’s ready”, standup, and blocked state are queries, so drift is structurally impossible. Commission does not write your code and does not replace your judgment; it is the layer everything else runs on.

— positioning.md §1.2, the canonical paragraph. Every surface quotes it rather than writing its own.

The five sections

section	what it is for	how to read it
Start here	Install commission and run one real task through it.	In order, once.
Guides	Task-shaped narrative: do this thing, end to end.	Pick the one that matches today’s problem.
Reference	Exhaustive, exact, mostly generated from source.	Look things up; do not read front to back.
Concepts	Architecture, principles, and why the design is what it is.	When you want to disagree with a decision, or extend one.
Contributing	How to work on commission, and how to write these docs.	Before your first pull request.

Reading paths

Four readers, four routes. Each is short on purpose — nobody reads documentation for pleasure.

Solo founder

You are the bottleneck on everything, and the failure you actually fear is losing a day re-deriving what an agent did yesterday.

1. Start here → install — clone, bun link, verify.
2. Start here → your first task — see a refusal, then satisfy it.
3. Start here → your first agent — hand the loop to a coding agent.
4. Guides → solo founder — idea to a shipped quarter, fanning agents out.
5. Reference → worked configurations — when two keys stop being enough.

Skip: execution policies, approvals, enterprise adoption, interop.

Engineer

You want to know what the commands do, what they refuse, and how not to be surprised.

1. Start here — the 90-second tour, run for real.
2. Guides → task lifecycle — claim, work, prove, close.
3. Reference → CLI and exit codes — the contract.
4. Guides → parallel work — ready, touches, and fan-out without collisions.
5. Concepts → architecture — one core, four thin consumers.

Engineering manager

You have to answer “who did this, under what authority, and how do we know it was verified” — without becoming the person who administers a process.

1. Concepts → architecture — what Commission refuses to do, and why.
2. Guides → enterprise adoption — incremental, non-displacing rollout, with an exit at every stage.
3. Guides → interop — keep Jira as the system of record; bind a subset.
4. Guides → execution policies — eligibility, autonomy, and approval as data.
5. positioning.md §8 — the shipped-versus-planned ledger, so nothing is bought on a promise.

Agent

You are operating commission, not reading about it. Prefer the machine surfaces.

1. commission prime — the operating manual, printed for pasting into CLAUDE.md.
2. commission next --claim — the context bundle is the documentation for the task at hand.
3. Reference → apply — the document format for planning a whole graph.
4. Reference → MCP — when Bash is unavailable.
5. Reference → CLI — every flag, every exit code.

Refusals are prompts: exit code 2 means the message names what is missing and the exact command that fixes it. Read it and act on it rather than retrying.

Two rules that keep these pages honest

Vocabulary is defined once. positioning.md §6 is the only definition of task, claim, gate, evidence, ready frontier, refusal, context bundle, and the rest. Documentation links there and never redefines them.

Some pages are generated. Reference pages derived from a schema are written by bun run generate:docs and bun run generate:config, and hand-editing them is reverted by the next run. Which is which, and how to write the rest, is Contributing → documentation.