DevOS

DevOS is a lazy SDD framework for one engineer or a small team. It keeps the process proportional to the task and makes the agent prove its work before calling it done.

You should not have to remember any of it. You type one thing, what you want changed, and DevOS decides what that needs: the route, the questions worth asking, the plan, the checks. It names the route before it starts, and the only thing it asks of you is a yes or an answer. A typo fix gets no ceremony. A new feature gets a short spec you approve before any code is written.

Works with Pi, Claude Code, Cursor, Copilot, Codex, and OpenCode. You do not need to know anything about spec-driven development to use it.

The Pi package is named @tduyng/pi-devos: pi names the tool it plugs into, devos the framework. OpenCode follows the same pattern with opencode-devos, and Claude Code, Codex and Copilot install a plugin named devos. The skills, the gates and the lifecycle are the same on every tool. If you installed pi-devos, you have DevOS for Pi.

The one command

/skill:build "let admins impersonate a user for support"

That is the whole learning curve on Pi. On Claude Code it is /devos:build "...", on Copilot and Codex the bare build "...".

DevOS reads the request, looks at the code it touches, and picks a route. There are eight.

| Size | The request looks like | What DevOS runs | | -------------- | --------------------------------------------------------------------------- | ----------------------------------------------------- | | F fog | a bare ticket title, a wish, an epic: it does not say what to change | frames it into tickets you can route, no code | | S small | a typo, a one-line fix, an obvious tweak | just does it, no spec, no gate | | M medium | a few files, clear behavior, a couple of edge cases | a one-page mini-spec, your go, then implement | | L large | a user-visible feature, several files, requirements you would have to guess | /devos:spec then /devos:implement | | B broken | something is broken and the cause is not obvious | reproduces first, then sizes the fix | | C reshape | a rename, a split, a framework upgrade, behavior unchanged | an invariant spec, then proves nothing else moved | | H hard | a direct attempt already failed a runnable check | manager plus fresh workers, the check is ground truth | | R research | "should we use Redis or in-memory here?" | a timeboxed investigation ending in findings, no code |

The C route has a second shape for a change that spans many units, or that moves code to a stack the project does not run today: a verdict first, a unit manifest the filesystem tracks, the shared decisions made once in your own rule files, and a judgment that runs against both trees. The manifest in the spec folder is what selects that shape, so a change that is not at scale reads none of it.

The lifecycle

Every route lands somewhere on the same five stages. Only the size decides how much of the middle runs.

   once per project                    every change
   ────────────────                    ───────────────────────────────────────────

   /devos:init  ──▶  FRAME ──▶ DEFINE ──▶ PLAN ──▶ BUILD ──▶ VERIFY ──▶ CLOSE
   map · vocabulary    │          │         │        │         │          │
   product knowledge   │          │         │        │         │          ├─ /devos:status
   wire AGENTS.md      │          │         │        │         │          │  where every spec stands
                       │          │         │        │         │          │
                       │          │         │        │         │          ├─ /devos:learn
                       │          │         │        │         │          │  keep a durable lesson
                       │          │         │        │         │          │
                       │          │         │        │         │          └─ behaviors updated
                       │          │         │        │         │             spec archived
                       │          │         │        │         │
                       │          │         │        │         ├─ verifier agent  (automatic)
                       │          │         │        │         │  runs the project's own checks
                       │          │         │        │         │
                       │          │         │        │         └─ /devos:review  [--gaps]
                       │          │         │        │            conventions review,
                       │          │         │        │            or a completeness scan
                       │          │         │        │
                       │          │         │        └─ /devos:implement  Phase B
                       │          │         │           code + tests
                       │          │         │
                       │          │         └─ /devos:implement  Phase A
                       │          │            spec.md (the plan capsule)
                       │          │            ══ GATE: you approve the plan ══
                       │          │
                       │          └─ /devos:build  or  /devos:spec
                       │             interview, then spec-functional.md
                       │
                       └─ /devos:frame   only when the ask does not say what to change
                          brief · impact · questions · tickets, then one route per ticket

Every entry command: build is the router, spec drives the interview yourself, implement runs an approved spec (and resumes it), init runs once per project. status, review, explain, and learn inspect or close work at any point.

Two gates block mechanically, not by asking the model nicely. Nothing is built before you approve the plan, and nothing is called done without a verification report that names the commands that passed. On an S route there is no plan to approve, and that is correct.

Install

Each tool installs DevOS through its own plugin or package command. No clone needed:

pi install npm:@tduyng/pi-devos                                                    # Pi
claude plugin marketplace add https://gitlab.com/tduyng/devos.git && claude plugin install devos@devos   # Claude Code
codex plugin marketplace add https://gitlab.com/tduyng/devos.git                   # Codex CLI
copilot plugin marketplace add https://gitlab.com/tduyng/devos.git && copilot plugin install devos@devos # Copilot CLI

Cursor copies the plugin from a clone (just cursor-install, see docs/install/cursor.md). OpenCode V2 points opencode.json at a clone too, because it has no marketplace and its package route cannot reach DevOS's gate scripts.

Editing DevOS itself? Clone and install the path instead:

git clone https://gitlab.com/tduyng/devos.git ~/code/devos
pi install ~/code/devos

Every tool also takes the git remote directly: pi install git:gitlab.com/tduyng/devos, claude plugin marketplace add https://gitlab.com/tduyng/devos.git, codex plugin marketplace add https://gitlab.com/tduyng/devos.git, copilot plugin marketplace add https://gitlab.com/tduyng/devos.git. Per-tool install, update and uninstall commands are in docs/install/.

Then, once per project:

/skill:init        # maps the codebase, defines vocabulary, wires AGENTS.md
/skill:build "your first real task"

Onboarding runs in the background too: if you skip it and run build, the router notices the project is unmapped and runs it first.

Per-tool detail is in docs/install/.

A worked example

$ /skill:build "let users export their invoices as PDF"

Sizing: L. Touches the report layer, has open questions.
Before I start:
  · Who can export: all users, or admins only?
  · Include line items, or a summary only?
  · Any size ceiling on a single export?

> admins only, line items, cap at 10k rows

Wrote the spec: devos/specs/2026-09-13-invoice-export/spec-functional.md
Read the Behavior delta, then I'll plan.

$ (you read it, say go)

Plan written to spec.md. Files: 4. Task groups: 3.
GATE: approve to start building.

> go

Building... verifier running `npm test` (0, 214 passed), `npm run lint` (0)...
Verdict: DONE. verification.md written.

Commands

You only need the first one. The rest are for when you want to drive a stage yourself or look something up.

| Command | What it does | | -------------------------------------------- | ---------------------------------------------------------------------------------------- | | /devos:build "..." | Size any change and run the right process. Start here. | | /devos:frame "..." | Turn a bare ticket or a wish into a brief, an impact map, owned questions and tickets. | | /devos:absorb <source> | Record what the product promises from a help centre or a published policy. | | /devos:spec | Interview you and write the functional spec, without building. | | /devos:implement | Plan, build, and verify an approved spec. Resume-aware. | | /devos:init | Map the codebase, define vocabulary, wire AGENTS.md. Once per project. | | /devos:status | Where every spec stands. --cost for framework cost, --compare a b for a spec diff. | | /devos:review | Review a diff against this project's own conventions. --gaps for a completeness check. | | /devos:explain | Walk back a change you did not watch happen. | | /devos:learn | File a durable lesson so it stops recurring. | | /devos:product | Mission, roadmap, backlog, tech stack. Plans read them when present. | | /devos:docs init\|update\|backfill\|status | Human-facing documentation built from your specs. The pipeline never reads it. |

Four rules load on their own, with no command to type: stay inside the agreed scope, never weaken a test to make it pass, name the evidence before claiming done, and follow the project's declared design direction.

What lives in your repo

Everything DevOS writes goes under devos/, version-controlled with your code:

devos/
├── standards/
│   ├── conventions.md           project decisions: checks, architecture, hard rules
│   └── rules/                   scoped rules, one file per rule, attached by glob
├── product/
│   ├── codebase-map.md          where things live
│   ├── domain-model.md          shared vocabulary, one page
│   ├── glossary.md              the product's words, mapped to the code's
│   ├── capabilities.md          each capability: articles, paths, entities, owner
│   ├── personas.md              who acts, through which channel, on which tier
│   ├── constraints.md           what law, contracts and platforms forbid
│   ├── knowledge/               rules distilled from sources outside the repo
│   └── behaviors/               what the product does today
├── frames/2026-11-11-kol-1234/
│   ├── brief.md                 the problem, the actor, today's behavior
│   ├── impact.md                every dimension, with evidence or where you looked
│   ├── questions.md             open forks, by owner, each with a default
│   └── tickets.md               the split, the fog, the out of scope
├── specs/2026-09-13-invoice-export/
│   ├── spec-functional.md       the contract
│   ├── spec.md                  the approved plan
│   ├── decisions.md             the choices made, and the ones rejected
│   ├── gates.md                 the checks a test cannot decide, when there are any
│   ├── manifest.tsv             the units of a change that spans many files
│   └── verifications/           the proof it works
└── deferred.md                   real findings, out of scope for now

There is no state file. Progress is derived from which files exist, so any session can resume any spec.

Why it stays cheap

About 576 tokens per session in pi: the skill catalog the harness renders at startup. The always-on rules' descriptions are about 177 of that, and nothing else loads until you type a command. /devos:status --cost shows the numbers for your install.

The evidence router

The review and planning stages read your declared evidence through a small script that ships with the plugin. It picks blocks by matching words, so it needs nothing installed beyond Python 3 and its standard library. The output is a reading list and nothing gates on it. docs/evidence-router.md has the flags and the scope.

Docs

| Page | What it covers | | ---------------------------------------------------- | ---------------------------------- | | docs/getting-started.md | First project, step by step | | docs/concepts.md | The moving parts and the lifecycle | | docs/commands/ | One short page per command | | docs/evidence-router.md | The optional evidence selector, measured | | docs/README.md | Everything else |

License

See LICENSE.