prorab

A set of Claude Code commands that take a task from a raw thought to verified, shipped code — and keep the codebase healthy while you do it.

Working with a coding agent usually breaks in two places. Either the idea goes in half-formed and you get a confident implementation of the wrong thing, or the agent burns an enormous amount of tokens re-reading the same files with no upper bound. Prorab addresses both: every command has a mandatory quality floor (a stated Definition of Done, a test that failed for the right reason first, independent verification) and a hard, counted budget it cannot exceed.

It ships as a Claude Code marketplace with two plugins. Commands install globally and update from git; the artifacts they produce (refined ideas, audits, implementation plans) stay in the project where you ran them, under version control.

Install

/plugin marketplace add aartem1/prorab
/plugin install prorab@prorab
/plugin install prorab-tech@prorab

Both plugins live in the same prorab marketplace but install separately — take one track or both. To update later: /plugin marketplace update prorab.

/plugin marketplace add /path/to/prorab
/plugin install prorab@prorab
/plugin install prorab-tech@prorab

Your first task

/prorab:refine  add a CSV export to the reports page

It asks you skeptical questions, reads the relevant code, and surfaces the contradictions and gaps you hadn't thought about. It writes no code. When the idea is spec-ready it saves tasks/ideas/IDEA-csv-export.md — including a Code map of everything it already read.

/prorab:build

Picks up that IDEA and implements it turnkey: recon → plan → DAG-ordered implementation → adversarial review → verification. No approval gate in the middle — the agents check each other. Result: working code plus tasks/IMPL-csv-export.md.

/prorab:verify

Checks the shipped result the way its users meet it — from outside the code, by a context that never reads the implementation, against expected values taken from the requirement. Then it makes sure a project test actually fails when that behavior breaks. Result: a verdict per behavior with evidence, plus tasks/verify/VERIFY-csv-export.md.

/prorab:announce

Turns the result into a short, factual message you can paste into a chat.

For a two-file change where all that ceremony costs more than the work itself, skip straight to /prorab:quick.

Which command do I need?

Picking a lane. refine → build is for anything that touches an external contract, spans several files or layers, or has a requirement that can be read more than one way. quick is for the daily two-file change. You don't have to guess right: quick re-checks its eligibility gate after reading the code and hands the task over rather than finishing it on the wrong budget, and refine points at quick when a settled idea turns out to be tiny.

The product track — prorab

raw idea ──/prorab:refine──▶ IDEA-<slug>.md ──/prorab:build──▶ code + IMPL ──/prorab:announce──▶ message
                             (carries a hashed Code map)          │
                                                                  └──/prorab:verify──▶ VERIFY + tests

small change ──/prorab:quick──▶ code + QUICK-<slug>.md   (escalates to refine+build if it isn't small)

/prorab:verify is optional and works on any scope — after build, after quick, or on a branch nobody used the framework for.

refine and build are deliberately not merged into one command; see the prorab 0.10.0 entry in the CHANGELOG for why the token saving people expect from merging is really recon reuse, which needs no merge.

The tech-quality track — prorab-tech

Two pairs, for two different natures of debt.

structural: ──/prorab-tech:audit──▶ AUDIT-<slug>.md (backlog + spec #1) ──/prorab-tech:refactor──▶ refactor + IMPL-refactor ──▶ /prorab:announce
static:     ──/prorab-tech:lint-audit──▶ LINT-<slug>.md (batch ladder)  ──/prorab-tech:lint-fix──▶ one pass + gate state + IMPL-lint (repeat) ──▶ /prorab:announce

Why these are separate executors from build. build proves that new behavior matches a requirement. refactor and lint-fix prove that old behavior did not change — a different verification discipline entirely. Their results are announced by the same /prorab:announce.

How does Prorab compare?

Prorab sits between a hand-written Claude Code setup and a full product-development framework. Its narrower bet is that an existing codebase needs two things at the same time: a repeatable path from an unclear task to verified code, and a separate, behavior-preserving path for paying down debt.

The closest popular, actively maintained approaches are compared below. This is a comparison of their documented default workflows as of 2026-07-25, not a benchmark of model output. All of them are extensible, so “not in the default workflow” does not mean “impossible to add.”

Capability matrix

Built in means the default documented workflow makes the capability explicit. Configurable means the approach provides a mechanism or extension point, but does not make one policy universal.

Choosing without ideology

• Choose Prorab when auditability, behavior-preserving maintenance and a hard context boundary are more important than agent portability.
• Choose Superpowers when you want a prescriptive TDD/subagent methodology that follows you across coding tools.
• Choose Spec Kit when specifications are the primary organizing artifact and you want a large integration and extension surface.
• Choose BMAD when the work starts before engineering — market/domain analysis, PRDs, architecture and UX — and role separation is useful.
• Use native Claude Code customization when the workflow is small or unusual enough that owning the policy is cheaper than adopting a framework.

Sources: Superpowers basic workflow, Spec Kit agentic SDD reference, BMAD workflow map and BMAD agent catalog.

What lands in your project

Commands are global; everything they write is local to the working project and worth committing — these files document what was decided and why.

tasks/
├── ideas/IDEA-<slug>.md                     # refine
├── IMPL-<slug>.md                           # build
├── quick/QUICK-<slug>.md                    # quick
├── verify/VERIFY-<slug>.md                  # verify
├── audits/AUDIT-<slug>.md                   # audit
├── audits/LINT-<slug>.md                    # lint-audit
├── IMPL-refactor-<slug>.md                  # refactor
├── IMPL-lint-<plan-slug>-batch-<id>.md      # lint-fix
├── memory/                                  # small, verified project memory
└── archive/<YYYY>/<task-slug>/              # completed, verified bundles

/prorab:quick leaves one short record and nothing else — no IDEA, no IMPL, no archive entry. It exists so the written history of the project doesn't skip small changes; if it can't be stated in about a screen, the change wasn't small. /prorab:announce produces its text in chat, and saves ANNOUNCE-<slug>.md into the archive directory only when the task is already archived. /prorab:ask changes no project code; at most it corrects or stales a disproved memory entry. /prorab:verify leaves one record and the tests it wrote, and archives nothing.

tasks/archive/
└── YYYY/
    ├── <task-slug>/
    ├── refactor-<task-slug>/
    └── lint-<plan-slug>/

Documentation doesn't drift away from the code

Every command that changes code owns the documentation that change falsifies. A stale document left behind counts as an incomplete change, not a follow-up — it is part of the command's completion condition and the reviewers treat a contradiction between the diff and a current-state document as a finding.

The line that keeps this from turning into an endless documentation project runs between two kinds of file:

Anything wider — a style rewrite, a documentation gap that predates the change, a restructure, or a correction that needs a product decision — is reported with the follow-up named, not absorbed into the diff. And "nothing was affected" has to be earned by actually searching the docs for the symbols, paths and values the change touched.

/prorab:verify sits deliberately outside this duty. It changes no behavior, so it falsifies no document — and when observed behavior contradicts a document, either one of them can be the wrong one. That is a finding it reports with both readings named, not a document it rewrites.

Cost is bounded, quality is not negotiable

The heavy commands (build, verify, audit, refactor, lint-audit, lint-fix) run a budget triage step before fanning out any agents: they estimate complexity from cheap signals — size, blast radius, novelty, reversibility, uncertainty — and pick a tier.

The count is cumulative for the whole command and includes the main context plus every delegated or Workflow context, retries included. You can pin the choice with --fast, --thorough, --tier=S|M|L or --verification=economy|balanced|thorough; the 16-context ceiling stays absolute.

A tier bounds how many contexts open, not how full each one gets — those are two different things, and a context stuffed with material nobody reads judges worse than one given the range that matters. So a second, orthogonal limit applies at every tier: raw output from a test suite or an analyzer never enters a context (it goes to a file outside the working tree and comes back as a ~40-line digest — command, exit code, counters, one line per failure), a delegated context returns a capsule of claims and path:line pointers rather than the material itself, and above the smallest tier the orchestrator holds the plan, the DoD table and the ledger while the reading happens in delegated contexts. At tier S the main loop is the executor and reads and runs directly — that is the intended shape of the cheap lane, not an exception to the rule.

Compaction never buys silence: the exit code and the failure counts are always reported in full. Shortening what failed is allowed; concealing that something failed is a false report.

The same principle applies to the commands' own text. The shared rules live in four contracts, and a command loads only the ones it can act on: project-knowledge.md (language, source-of-truth order, memory, delegated-return capsules, archive) is read by all ten; execution.md (run output and main-loop discipline, deterministic steps) only by the seven that run checks or analyzers; documentation-sync.md only by the four that change product code; and web-probing.md (the headless instrument ladder, the locator rule, the runner) only by build, quick and verify, and only when the scope in front of them actually has a browser surface. ask, announce and refine load neither of the middle two, which is where the biggest part of their prompt used to go, and verify skips documentation sync — it writes tests, never behavior.

What the budget never buys back: the safety floor is non-negotiable at every tier — the characterization net or baseline, the contract diff, the drift search, a DoD skeptic, and a sabotage-proven gate whenever one is created or changed.

Project memory

Prorab builds a small, version-controlled memory during normal work. There is no init, no remember command, no background process, no external model, no vector database — the structure is created lazily under tasks/memory/ (INDEX.md, components/, decisions/, gotchas/, verification/).

Memory is deliberately last in the source-of-truth order:

current worktree → repository instructions/docs → tests/CI/executable evidence → task artifacts → memory

A material memory claim must be checked against current source before it can affect behavior, architecture, contracts, Scope, DoD, implementation or verification. A conflict marks the entry updated, superseded or stale — it never overrides the code. Missing memory never breaks a command.

Capture is automatic but selective: durable decisions, boundaries, contracts and consumers, recurring gotchas, rejected alternatives, re-verified commands. Not stored: transcripts, reasoning, temporary status, ordinary code facts, unmarked assumptions, or copies of task artifacts.

Language

Command bodies and all internal work run in English — reasoning, inter-agent prompts, schema outputs. It is denser in tokens and steadier in quality.

Everything a human reads is in the task's language, detected from how you phrased the request (Russian by default): the chat, the refine dialogue, the announce text, and the IDEA/IMPL/AUDIT/LINT artifacts, which stay project documents in that language. Code, names, comments and commit messages are always English. User-visible domain and UI terms are carried as-is, never round-tripped through a double translation.

Developing the framework

prorab/
├── .claude-plugin/
│   └── marketplace.json           # marketplace manifest (both plugins)
├── plugins/
│   ├── prorab/                    # product track
│   │   ├── .claude-plugin/plugin.json
│   │   ├── commands/              # refine.md build.md quick.md verify.md announce.md ask.md
│   │   ├── references/            # project-knowledge.md execution.md documentation-sync.md web-probing.md
│   │   └── README.md
│   └── prorab-tech/               # tech-quality track
│       ├── .claude-plugin/plugin.json
│       ├── commands/              # audit.md refactor.md lint-audit.md lint-fix.md
│       ├── references/            # project-knowledge.md execution.md documentation-sync.md
│       └── README.md
├── tests/test_contracts.py        # manifests/frontmatter + lifecycle scenario checks
├── README.md
└── CHANGELOG.md

Adding a command

1. Drop plugins/<plugin>/commands/<name>.md (frontmatter description / argument-hint, then the prompt body) into the right plugin — prorab for product, prorab-tech for tech quality.
2. Bump version in two places: that plugin's .claude-plugin/plugin.json and its entry in the root .claude-plugin/marketplace.json. The two plugins are versioned independently.
3. Add a CHANGELOG.md entry.
4. /plugin marketplace update prorab — the command is now available as /<plugin>:<name>.

The same version-bump rule applies to any change to an existing command.

More detail: plugins/prorab/README.md · plugins/prorab-tech/README.md · CHANGELOG.md