Repave IDE commands

Every Repave IDE session comes with the Repave plugin installed for Claude Code, and an equivalent one for Codex. The plugin gives the agent in the session the same feature loop the platform runs — write the feature file, implement, write the tests, run them, review, upload the results — as commands you type, one step at a time or all at once.

Using them

• In Claude Code, type /repave: to list them, then pick one: /repave:test, /repave:implement. Arguments go after the name: /repave:commit Add the account search.
• In Codex, the same commands have no repave: prefix — /test, /implement — and can also be started as skills: $test, $implement-loop.
• You do not have to use the command. Each one is also a skill the agent picks up from plain language: "run the tests", "review this feature" and "start UAT" do the same as the command.

Which feature a command acts on

Commands that take a [feature-id] resolve it the same way:

1. the feature you named, if any;
2. otherwise the feature the session was opened for — a feature session is opened for exactly one;
3. otherwise the agent lists the project's features and asks.

A feature session can read the whole project but write only to its own feature. A command that tries to write to another feature is refused by the server.

What no command does

Three decisions stay with the platform or with you, whichever command you run:

• No command marks a feature completed. /repave:upload-test-result sends a test run's evidence to Repave, and the server decides from the actual results. A clean review, a green local run and a watched walk in the browser are not completion.
• No command selects or approves a UI prototype option. The prototype commands produce and check options; choosing one is yours, in the feature's Design view.
• No command opens a pull request or merges. /repave:commit commits, and /repave:push-to-remote pushes the branch the way the page's Push does; opening pull requests and merging stay on the feature's page.

Product code also cannot be written until the feature's implementation preflight has concluded. The session enforces this itself, so an implementation command run too early stops and tells you to run Preflight from the feature page.

At a glance

Command	What it does
/repave:feature-file	Writes the feature's approved scenarios into the worktree's .feature file.
/repave:implement	Writes the product code. No tests.
/repave:implement-live	Writes the product code with the app running, and walks each scenario in the browser. No tests.
/repave:cucumber	Writes the test code for the scenarios. No product code.
/repave:test	Runs this feature's BDD tests.
/repave:test-all	Runs every feature's BDD tests, to catch regressions.
/repave:code-review	Runs the platform's review checks locally. Advisory.
/repave:upload-test-result	Sends a test run's results and traces to Repave.
/repave:commit	Makes one clean commit of the feature work.
/repave:push-to-remote	Pushes the branch you have checked out, the way the page's Push does.
/repave:implement-loop	Runs implement → tests → review end to end, with fix cycles.
/repave:prototype-generate	Generates UI design options for the feature.
/repave:prototype-validate	Checks design options against the project's prototype rules.
/repave:prototype-update	Changes one design option from an instruction.
/repave:prototype-loop	Runs generate → validate → fix, then stops for you to choose.
/repave:dev-start	Runs the app in dev mode, so edits show as they are saved.
/repave:dev-status	Says which parts of the dev-mode app are running.
/repave:dev-stop	Stops the dev-mode app.
/repave:uat-start	Starts the built UAT environment for manual testing.
/repave:uat-stop	Stops the UAT environment, keeping its data.
/repave:gen-test-data	Seeds realistic test data into a UAT database and commits it.
/repave:uat-open	Shows the running app in the Repave Browser panel for you to use.
/repave:interactive-test	Walks one scenario through the running app while you watch.

A typical feature

1. /repave:feature-file — only if the worktree has no .feature file yet, or you want the newer scenarios from the platform.
2. /repave:implement (or /repave:implement-live to watch it work as it is built).
3. /repave:cucumber, then /repave:test until it passes.
4. /repave:code-review, and fix what it finds.
5. /repave:upload-test-result, then /repave:commit.

/repave:implement-loop runs steps 1–4 for you; you still finish with step 5.

Which implement command

All three write the same product code from the same sources. They differ in what checks the result:

	Starts the app	Writes tests	Checks the result by
/repave:implement	No	No	Nothing — it hands off to /repave:cucumber and /repave:test
/repave:implement-live	Yes, in dev mode	No	Walking each scenario in the browser while you watch
/repave:implement-loop	Only to run the tests	Yes	Unit tests, the BDD suite and the review checks, with fix cycles

The implementation loop

/repave:feature-file

/repave:feature-file [feature-id]

Writes the feature's approved To-Be scenarios from Repave into the worktree's .feature file — the file the BDD tests run. The platform decides where the file goes: the project's features folder, and the existing file's name if there already is one.

Opening a session writes this file only when the worktree has none, and never over one that is there. Run this command when you want the platform's newer scenarios in a file that already exists.

• It replaces your copy. If the file has edits that are not in Repave, the agent shows you the diff and asks before overwriting. Edits you made while implementing reach Repave through /repave:upload-test-result, not by being kept here.
• It refuses a feature whose To-Be scenarios have not been generated yet. Until then the stored scenarios are the As-Is (legacy) draft, and implementing against those would reproduce the legacy behaviour. Generate the To-Be scenarios in the web app first.
• A file that is already up to date is left untouched, so your editor does not reload.

/repave:implement

/repave:implement [feature-id]

Writes the product code for the feature's approved scenarios — schema and migrations, services, API routes, UI, adapters, batch jobs — and nothing else. It works from, in order of precedence:

1. the approved To-Be scenarios, which win any explicit conflict;
2. the answers given at preflight for this launch, which settle what the scenarios leave open;
3. the legacy code each scenario traces back to, for the detail the scenarios do not state — validation order, exact messages, defaults, rounding;
4. the project's To-Be architecture, for where the code goes and which stack it uses.

For UI scenarios it builds from the approved design and inside the application shell, and when the feature's branch starts with a target-stack prototype it builds on that prototype in place. It follows the project's database and external-system decisions.

• It writes no tests. That is /repave:cucumber — writing the code and its tests in one pass is how a test ends up shaped around the code instead of the scenario.
• It never edits the .feature file. If a scenario turns out to be wrong, the agent raises it with you instead of rewording it to match the code.
• It stops when scenarios are not approved, when preflight has not concluded, or when a preflight answer cannot be implemented — it reports the conflict rather than picking a different answer.

It finishes by reporting what it built per scenario. Nothing has run yet, so it never claims a scenario passes.

/repave:implement-live

/repave:implement-live [feature-id]

Implements the feature the same way as /repave:implement, but with the app running in front of you:

1. checks the scenarios are approved and preflight has concluded — before starting anything;
2. starts the app in dev mode, exactly as /repave:dev-start does, reusing any parts already running;
3. opens the Repave Browser panel;
4. writes the product code;
5. walks each scenario a browser can reach, one narrated action at a time, checking the console and network requests as well as the screen;
6. fixes what the walk exposes and walks that scenario again, up to the project's review-cycle limit (three when the project does not set one).

Each scenario ends verified in the browser, still failing (with the step, what it saw, and a screenshot), or not verified — which is every scenario with no screen, such as a batch job.

• It writes no tests, neither Cucumber nor unit tests. A watched walk is not a test: the scenarios still need /repave:cucumber and /repave:test.
• It needs the panel open. If the Repave Browser panel is not open, it stops before writing any code; open it from the Command Palette with Repave Browser: Open and run the command again.
• The dev-mode app is left running when it finishes; /repave:dev-stop takes it down.

/repave:cucumber

/repave:cucumber [feature-id]

Writes the test code — step definitions, support code, fixtures — that proves each approved scenario, then runs the suite once to check it is wired up.

Each scenario is tested through its real entry point: a UI scenario through the browser, clicking and asserting on what is on screen, reached the way the scenario describes rather than by jumping to a URL; an API scenario with real HTTP calls; a batch scenario by launching the real job; a messaging scenario through the real broker. Database or API shortcuts are fine for setting up a Given, never for the action or the check. Where the legacy code states an exact message or boundary the scenario only describes, the test asserts the real value.

• It never touches product code. If a scenario fails because the product is wrong, it says so and hands back to /repave:implement.
• It never weakens a test or rewords a scenario to get a green run.
• If the worktree has no .feature file, it runs /repave:feature-file first rather than writing one.

/repave:test

/repave:test [feature-file-or-id]

Runs the feature's BDD tests with the project's test runner and reports what actually happened. The runner, the features folder and the run output can live in a different folder per project — in a project spanning several repositories they live in a shared test folder — and the command asks the platform where rather than guessing.

On a failure it reports the failing steps and assertions from the log, and says where the fix belongs: the product (/repave:implement), the test (/repave:cucumber), or the environment.

• A run takes a while: it installs dependencies before any test starts.
• It uploads nothing. Sending the results to Repave is /repave:upload-test-result.

/repave:test-all

/repave:test-all

Runs every feature's BDD tests, not just this one's. Use it to find out whether this feature's work broke one that was already done. It is much slower than /repave:test.

Failures are grouped by feature, and failures in other features come first — those are the regressions. A feature that was already failing before your change is reported as such, not blamed on it.

/repave:code-review

/repave:code-review [feature-id]

Runs the same checks Repave runs after an implementation, locally and in parallel, and reports the findings as advice:

• the implementation review — scenario coverage, target-stack correctness, equivalence with the legacy behaviour the scenarios preserve, security, and tests that pass without proving anything;
• the project's validation rules, in the same groups the platform checks them in;
• the UI check against the approved design, when the project enables it and the feature has UI scenarios;
• unit-test coverage against the project's threshold, when the project enables unit tests.

It reads which checks are enabled from the project settings, and lists which ran and which it skipped and why.

The most serious finding is a false positive: a test that passes without proving the behaviour — a UI scenario checked through the database, an assertion that is always true. A green run built on one is not coverage.

• It never edits. It offers to fix specific findings.
• It is not a gate, and a clean review does not complete the feature.

/repave:upload-test-result

/repave:upload-test-result [feature-id]

Sends the most recent BDD run's results and Playwright traces to Repave. This is the step that closes the loop: the server checks the tested .feature file and marks the feature completed only if every scenario passed. The traces then appear on the feature's page; see Test runs and reports.

• It does not run tests. Before uploading, the agent checks nothing has changed since the run; if anything has, it asks you to run /repave:test again rather than upload results for code that no longer exists.
• Scenario edits go with it. If you reworded a scenario in the .feature file while implementing, the server saves the tested file as the feature's To-Be scenarios, so the platform shows exactly what was tested. A file whose annotations are invalid is refused and nothing is uploaded; fix the annotations, run the tests, and upload again.
• It reports the server's verdict as given — completed, or not completed with the failing scenarios.

/repave:commit

/repave:commit [message]

Makes one commit of the feature's work — product code, step definitions, unit tests, the .feature file, schema, configuration, documentation — and keeps out what the test and UAT runs generate: run folders, traces, screenshots, reports, coverage output, logs and dependencies. Recurring noise gets the narrowest possible .gitignore entry. Your message becomes the subject if you give one.

• It only commits. It does not push, open a pull request, or merge.
• It reports the commit and what went into it, and leaves the working tree clean.

/repave:push-to-remote

/repave:push-to-remote

Pushes the branch you have checked out — a feature's or a worktree's — exactly as that feature's or worktree's Push button does. On a project that combines several repositories, the branch is split and each repository it touches gets its part.

• It commits first. Anything uncommitted is committed with /repave:commit, so you see the commit before it is pushed.
• It asks one question at most: whether to overwrite a source repository whose branch has commits that were not made in Repave. Nothing else is asked.
• It reports one line per repository: pushed, no changes, not pushed, or failed and why.
• It opens no pull request. The same push is available as repave push in the terminal, with --preview to see what would happen first.

/repave:implement-loop

/repave:implement-loop [feature-id]

Runs the whole loop in one pass, the way the platform's own implementation run does:

Stage	What happens
Context	Reads the feature, the project settings and the preflight answers, and writes the .feature file if the worktree has none
Implement	Product code, as /repave:implement
Unit tests	When the project enables them, checked against its coverage threshold
Cucumber	Test code, and a real BDD run
Review	The code review and the UI check, in parallel

A failed stage feeds its findings into a fix cycle, up to the project's review-cycle limit. Unit tests and the BDD suite re-run every cycle; a review check that passed stays passed.

• An existing .feature file is used as it is, edits included. To take the platform's version instead, run /repave:feature-file before the loop.
• It stops at the start when scenarios are unapproved, there are no To-Be scenarios, or preflight has not concluded.
• It never uploads results. When every check is green it points you at /repave:upload-test-result and /repave:commit.

The prototype loop

These run before implementation, to settle the design. They produce options and verdicts; none of them selects an option or approves one — see UI prototypes.

When a command acts on one option, it decides which the same way: the option you named with --option N; every option with --all; the only option, if there is just one; otherwise it asks. Being marked active is not enough — after a generation, option 1 is active by default, not because anyone chose it.

/repave:prototype-generate

/repave:prototype-generate [feature-id] [--count N] [--append] [--regenerate]

Generates design options for the feature in the session — three by default, --count takes one to five — and submits them to Repave. Before drawing anything it reads the approved scenarios, the application shell, the feature's reference images, its views and navigation path, and the project's personas.

Each option renders inside the shared application shell, shows every user-visible string the scenarios name exactly as written, draws every state the scenarios reach (empty, error, validation, not just the happy path), and differs from the others in layout, workflow or information architecture — never colour alone. Where a reference image contradicts the scenarios, the scenarios win and the agent says so. In a Figma-mode project it works in Figma instead.

• It refuses when the feature already has options, and points at /repave:prototype-update and /repave:prototype-validate. --regenerate replaces the whole set, after the agent confirms how many options you would lose. --append adds the new options after the existing ones.
• It ends by saying what each option is for, and leaves the choice to you.

/repave:prototype-validate

/repave:prototype-validate [feature-id] [--option N | --all]

Checks the design options against the project's prototype-stage validation rules, in parallel and in the same groups the platform uses, plus an accessibility scan when the project enables it. Each option's verdict is recorded on the platform. Every option is checked unless you name one.

The report lists each option's findings, most severe first, and which rules and checks ran or were skipped.

• It never edits an option. Fixing a finding is /repave:prototype-update.
• Passing makes an option eligible, not chosen.

/repave:prototype-update

/repave:prototype-update [feature-id] <instruction> [--option N | --all]

Changes a design option from a plain-language instruction — "move the filters above the table", "fix the findings on option 2" — and saves it. This is the conversational version of the Rebuild dialog.

• It changes only what you asked for. It does not restyle or rename anything else.
• It refuses changes to the navigation, header or layout chrome, which belong to the application shell, and asks before a change that would contradict an approved scenario.
• Updating the active option updates the feature's active design with it.

/repave:prototype-loop

/repave:prototype-loop [feature-id] [--count N]

Runs generate → validate → fix in one pass, re-checking only the options that still have findings, up to the project's review-cycle limit — then stops for you to choose in the Design view. It reports "awaiting selection", never "done": the prototype is not settled until a person picks an option.

• If the feature already has options and none is active, it validates those rather than generating over them. If one is active, it refuses, as /repave:prototype-generate does.
• It stops at the start when the feature has no approved To-Be scenarios to design against.

Dev mode

Dev mode is the edit loop: every part of the app runs in its watch mode, so an edit shows in the Repave Browser panel as soon as it is saved. Nothing is built for release. For the built app a reviewer clicks through, use UAT.

/repave:dev-start

/repave:dev-start

Starts the database, then the backend or backends, then the frontend, each in its watch mode, and shows the app in the Repave Browser panel. It works for any stack, using the project's own dev configuration, its own ports, and its database image.

• Run it again and it leaves running parts alone, starting only what is down.
• It reuses this checkout's own dev servers if you started them some other way, instead of fighting over their ports. A port held by anything else is reported, never killed.
• It prefers environment variables over editing files. A tracked file it had to change is listed for you, and nothing is committed.
• What it started is recorded in the checkout (kept out of git), so the other two dev commands act on exactly that.

/repave:dev-status

/repave:dev-status

Lists each part of the dev-mode app as up, starting or down, with its address and log. It checks what is actually running rather than trusting the record, and never starts or stops anything. If parts are down, /repave:dev-start restarts only those.

/repave:dev-stop

/repave:dev-stop

Stops what /repave:dev-start started, and nothing else.

• The database's data is kept for the next start, unless you ask for a clean database.
• Servers that were already running before /repave:dev-start reused them are left running.
• Files changed to run in dev mode stay changed; it lists them so you can decide.

UAT and checking by eye

/repave:uat-start

/repave:uat-start [uat-target]

Starts the project's UAT environment — the built app a reviewer or tester clicks through — and reports its address. Each UAT target has its own database: it uses the target you name, otherwise the session's feature's target, and says which. It does not fall back to Main silently, because other targets are cloned from Main.

• It refuses to restart an environment that is already running, because starting rebuilds the app and re-provisions its databases, which would wipe a session someone is testing in.
• To edit the app and see changes live, use /repave:dev-start instead.

/repave:uat-stop

/repave:uat-stop

Stops the UAT environment. Database data is kept, so the next start comes back with the same data. Wiping the database is a separate decision the agent takes only when you ask for a reset, and confirms first for Main. Seed files committed by /repave:gen-test-data survive a reset; data entered by hand does not.

When several UAT targets share one database server, it stops only this target's app, and the shared database only once nothing else uses it.

/repave:gen-test-data

/repave:gen-test-data [what to generate]

Inserts test data a tester can actually use — realistic, readable values, a handful of rows unless you ask for more — into the right UAT target's database, then commits it as a seed file under scripts/uat/seed/ so it survives a database rebuild and travels with the branch. You can hand it a CSV, JSON, spreadsheet or SQL file as the source data.

• Everything goes in one transaction, so a failure leaves no partial data.
• Each seed file is recorded in the database, so it is never applied twice.
• It never restarts a running environment to get at its database.

/repave:uat-open

/repave:uat-open

Opens the running app in the Repave Browser panel beside the editor and hands it to you: click, type, follow links and use the address bar as in any browser. Pick turns the cursor into a component picker — click part of the app to file a bug report about it.

It never starts the app and never drives it.

/repave:interactive-test

/repave:interactive-test [scenario title]

Walks one scenario through the running app in the Repave Browser panel while you watch, saying what it is about to do before each action and checking each Then against what is on screen. It stops at the first step that does not match, with a screenshot, console errors and failed requests. With no scenario named, it lists them and asks.

• It never starts the app and never edits code during the walk.
• A watched walk is not a test: the scenario still needs /repave:cucumber and /repave:test.

Knowledge skills

Besides the commands, the plugin carries knowledge skills: short guides to one kind of work, such as the Gherkin format or how to read a Figma design. Agents load them as they need them — the platform's own agents use the same set — so you will see them named in an agent's output. You can also invoke one yourself, for example /repave:gherkin-format, to put that guidance in front of the agent before asking it to do the work.

Gherkin and scenarios

Skill	Covers
gherkin-format	The layout every feature file follows: Feature, Rule and Scenario structure, one When/Then per scenario, data tables.
gherkin-annotations	The comment annotations (@id, @entrypoint, @views, @apis, @tables and the rest), where each goes, and how to choose a scenario's entry point. See Writing Gherkin.
gherkin-quality-review	The ten quality dimensions scenarios are written and reviewed against.
gherkin-correcting-a-scenario	Correcting a wrong scenario while implementing: keep its title and @id, minimal edits, report every change.
gherkin-split-combine-rearrange	Moving scenarios between features without losing annotations or legacy coverage.
nfr-classification	When something is a non-functional requirement, and how to record one.

As-is specification

Skill	Covers
legacy-call-chain-tracing	Finding a feature's legacy code and tracing its whole call chain, from entry point to data.
as-is-behavior-checklist	Listing every validation, branch, calculation and side effect in the traced code, to decide how many scenarios are needed.
as-is-code-ref-evidence	Giving every as-is scenario line ranges verified in the legacy source.
legacy-code-cover-or-tag	Leaving every inspected range of legacy code covered by a scenario or tagged as holding no business logic.
as-is-registry-annotations	Reusing the project's registered views, APIs, jobs and systems before adding new ones.
as-is-saving-features	Saving as-is scenarios without creating a duplicate feature.

To-be specification

Skill	Covers
to-be-from-as-is	Turning legacy scenarios into the to-be contract at each modernization level.
to-be-traceability	How a to-be scenario links back to legacy behaviour (@from-asis, @new-scenario).
to-be-catalog-registration	Declaring and registering the modernized views, APIs, batch jobs and messages a scenario uses.
to-be-saving-gherkin	Saving to-be scenarios safely, with a dry run first.
to-be-architecture	Reading the project's target architecture and decisions, and how much they outrank.
database-modernization-policy	What retain, modernize, replace and retire mean for legacy tables and procedures.
external-system-keep-replace-abandon	What keep, replace and abandon mean for each external system, in the contract, the code and the tests.

Implementation

Skill	Covers
implementation-ui-api-or-batch	Deciding whether a scenario is a UI page, an API, a batch job or a message handler, and what each layer needs.
implementation-from-annotations	Using a scenario's annotations as the map for implementing it.
implementation-completeness-review	Reviewing an implementation against its scenarios and the legacy behaviour they preserve.
implementation-smoke-check	The last sanity check: start the app and load the page, call the endpoint, or run the job.
report-templates	Implementing a scenario that produces a report from a template.
stack-nextjs-prisma	Conventions for a Next.js and Prisma target.
stack-spring-batch	Implementing a batch workload with Spring Batch on a Java target.
lint-resolution	Leaving touched code lint-clean in any stack.
dev-stack-running-the-app	Running the app in dev mode, using it in a browser, and stopping it.

Testing

Skill	Covers
cucumber-step-definitions	Step definitions that genuinely prove a scenario, per entry point.
bdd-false-positive-review	Telling whether passing tests actually prove their scenarios.
running-bdd-tests	Running the project's BDD suite once and reading its results.

UI design and prototypes

Skill	Covers
design-language-discovery	Finding the modernized app's existing design language before designing anything.
design-md-writing	Writing the project's design-system document and the stylesheet that encodes it.
shell-designing	Designing the application shell: the navigation and chrome every screen shares.
shell-from-navigation-map	Turning the project's navigation map into the shell's navigation.
shell-reference-images	Following reference images attached to the shell exactly.
shell-building-inside	Building a feature's prototype inside the shell rather than copying its chrome.
feature-reference-images	Using reference images attached to a feature, and where they rank against the scenarios.
prototype-building-to-match	Building the real UI to match the active prototype.
prototype-comparing-build-to-design	Comparing a built screen with its design, state by state.
prototype-design-vs-scaffolding	What in a prototype is the design and what is annotation that never ships.
prototype-component-ids	The stable ids every part of a prototype carries.
prototype-pinned-comments	Acting on review comments pinned to elements of a prototype.
prototype-validating-against-rules	Judging prototype options against the project's validation rules.
prototype-target-stack-codebase	Changing the shared target-stack prototype code without disturbing other features.
figma-design-reading	Reading a feature's Figma design in the right order.
figma-authoring	Building or updating a design in the project's Figma file.

Working in a project

Skill	Covers
repave-cli-usage	The Repave CLI commands agents use to read and write project data.
efficient-code-reading	Searching and reading a codebase without wasting time or context.
memory-searching-past-runs	Searching the project's memory of earlier agent runs, and checking what it recalls.
output-language	Writing everything a person reads in the project's chosen language.

Next: Repave CLI.