Documentation
T25, from invite to first task.
T25 is a local orchestrator that takes a task and walks it through briefing, flight plan, human gate, implementation, QA and release, all the way to the pull request. It runs on your machine, with the agent CLIs you already pay for. These docs cover what exists today.
Early access. The product moves fast and part of the code is still called factory under the hood. When these docs summarize a file from the repository, the file is the source of truth, and each page says which one it is.
Start here
If this is your first time: download the package with your invite, open a task from the CLI (headless) or bring up the cockpit, and approve the gate. MCP and the REST API cover the same cycle without a UI.
Quickstart
Download with your invite, install, bring it up on localhost:4173 and open the first task.
Guides
What already exists as a guide, and what still lives as a document in the repository.
Architecture
Control plane, worker and cockpit, and why your code only lives in one of them.
Configuration
The sections of t25.yaml: state, routing, limits, risk, auth.
CLI and MCP
The t25 commands and the npm run mcp stdio server for your agent.
API reference
REST and SSE, the same contract used by the cockpit, by MCP and by a headless script.
Specifications
Specs, plans and ADRs: where each design decision was recorded.
The mental model
Worth reading before any command, because almost every operational question lands on one of these three points.
A task is a state machine
The task walks through RECEIVED → SPEC → PLAN → AWAITING_APPROVAL → IMPLEMENTING → QA → REVIEW → PR_OPEN → DOCS → DONE, with NEEDS_INPUT, FAILED and CANCELLED as exits. An illegal transition is refused in one place, not in each caller. QA and review can send the task back to implementation.
Two stops are human
The task stops at SPEC until you approve the briefing, and stops at AWAITING_APPROVAL when the project policy or the risk level requires it. Merging the pull request is never T25's call.
No agent touches your checkout
Every task gets a git worktree of its own, on a branch named after the task type (feat/<id>, fix/<id> and so on). The agent CLI runs inside it, through argv and without a shell. That is the invariant everything else rests on, including running the factory on one host and the code on another.
Where everything lives
| When you want to | Go to |
|---|---|
| Bring it up and watch it run | Quickstart |
| Understand the design | Architecture |
| Change routing, limits or risk | Configuration |
| Operate from the command line or MCP | CLI |
| HTTP, SSE, scripts without a UI | API reference |
| Find out why something was decided this way | Specifications |
| Find out what doesn't exist yet | LEFTOVERS.md |