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.

Changing a command, or adding your own

The commands and knowledge skills on this page are what Repave ships. A project can change them: on the Skills page, under Management in the project sidebar, a project edits any of them for that project only, and Add skill adds a command or skill of the project's own, which sessions started after the save get alongside Repave's. Where a project has edited a command, its session follows the project's version rather than what this page describes.

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 your feature. /repave:commit commits, and /repave:push-to-remote pushes the branch the way the page's Push does; opening the feature's pull request and merging stay on the feature's page. The setup commands hand their files to Repave, which lands them on your base branch exactly as its own setup jobs do — as a pull request when your project lands platform changes that way.

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:legacy-parity	Finds anything the legacy feature had that the modernization lost, and the stage that lost it.
/repave:scan-reusable	Finds code this branch writes that the base branch already has, and offers to use it.
/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:git-fetch	Brings origin/* up to date with the project's remote, so you can merge or rebase on the latest main.
/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:make-repavable	Runs every setup step your codebase still needs, in order.
/repave:dev-config	Writes or repairs the app's dev configuration, and submits it.
/repave:bdd-config	Writes or repairs the BDD test runner for a codebase you provided, and submits it.
/repave:unit-test-config	Configures your unit-test suites to report coverage, and submits them.
/repave:uat-config	Writes or repairs the UAT configuration, and submits it.
/repave:design-discover	Writes the design system and its stylesheet tokens, and submits them.
/repave:setup-storybook	Sets up Storybook for Storybook prototypes, and submits it.
/repave:claude-md	Writes or refreshes the codebase's agent instructions file, and submits it.
/repave:seed-database	Writes the dev database's sample-data seed, and submits it.
/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. Run /repave:legacy-parity here too, to catch anything the legacy feature had that is still missing, and /repave:scan-reusable, to use what other features have already merged instead of writing it again.
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:legacy-parity

/repave:legacy-parity [feature-id]

Finds anything the legacy feature had that the modernization lost, and says where it was lost. A detail can drop out at any step on the way from the legacy code to the new one: when the As-Is scenarios are written, when the To-Be scenarios are written, in the prototype, or in the code itself. Every later step then looks correct, because it matches the step before it.

1. It lists everything the legacy feature has, read from the legacy code itself rather than only the lines the scenarios cite: fields, grid columns, request and response fields, table columns, dropdown and code values (including the code table they come from), sections, buttons and other actions, validations and their exact messages, calculations and other rules, role checks, and side effects such as audit records, messages and files.
2. It looks for each one in the As-Is scenarios, the To-Be scenarios, the prototype and the implementation. It checks the implementation at the database, the API and the screen, against the app running in dev mode, in the Repave Browser panel. It checks only as far as the feature has got.
3. It reports each missing or changed item with the step where it was first lost, and the legacy file and line that show it existed. An item the To-Be scenarios, a preflight answer, the database modernization policy or the API specification removed on purpose is listed as dropped by design, with what removed it, and is not counted as a loss.
4. It asks you once which losses to fix, then fixes them in order: As-Is, To-Be, prototype, then the code. You see each scenario change before it is saved. It never chooses or approves a design option for you.

• It only reads the database. It never changes data to check it.
• The As-Is never drops anything by design. The As-Is describes what the legacy system did, so a detail missing there is always a loss.
• If the Repave Browser panel is not open, it still checks the database and the API on the running app, and checks the screen from the code. Open the panel with Repave Browser: Open and run it again to walk the screens.
• /repave:implement and /repave:implement-live use the same list as their checklist before writing code, and check against it before they finish. They fix what is missing in the code, and report losses in the scenarios or the prototype for you to fix with this command.

/repave:scan-reusable

/repave:scan-reusable

Finds what this branch writes that the project's base branch already has: a function, service, component, endpoint or stored-procedure wrapper that does the same job. Features built at the same time each write their own copy of a shared helper, because neither can see the other's branch. Once one of them is merged, this command finds the second copy before it is merged too.

It looks for the same job, not the same text. Two features rarely write a helper the same way, so it describes what each new piece of code does and searches the base branch for code that does that, by its domain words, the tables, stored procedures and endpoints it touches, and its inputs and outputs. It reads every candidate before calling it a match.

1. It brings the base branch in first. Repave brings the base branch up to date, which on a combined workspace means syncing every source repository. If your branch does not already contain it, the command merges it in. It does not merge while you have uncommitted changes, and when the merge conflicts it puts your branch back exactly as it was and names the conflicting files for you to resolve. In both cases it still scans, against the base branch as it is.

2. It lists what your branch adds, including work you have not committed yet, and searches the base branch for each piece.

3. It reports each match with the file and line of both copies and what they share:

   • Use main's: the base branch's version already does everything yours does.
   • Extend main's: the base branch's version needs one more case, which it names. You decide whether to extend it, because that changes every place that already uses it.
   • Not sure: it shows its evidence and leaves the decision to you.

   For each stored procedure your branch calls, it shows where the base branch already calls it and, when the database modernization policy covers it, whether it is retained or modernized. The full report, including what it ruled out, is saved to .repave/reports/scan-reusable.md.

4. It asks you once whether to switch your branch to the base branch's versions of the Use main's matches. If you say yes, it changes only your branch's code, then runs the feature's tests. If they fail, it undoes its own changes and tells you which test failed.

• It never changes the base branch's code, and it never pushes.
• The merge of the base branch is the only commit it makes. You review and commit the switch yourself, with /repave:commit.

/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:git-fetch

/repave:git-fetch

Brings your checkout's origin/* branches up to date with the project's remote. A Repave IDE checkout holds no credential for the remote, so git fetch and git pull fail there; this command asks Repave to fetch with the credential it holds, and the refs appear in your checkout.

• It touches only origin/*. Your branch and your uncommitted work are left as they are. Ask it to merge or rebase on origin/main and it does that locally afterwards, stopping on a conflict.
• On a project that combines several repositories it first syncs the client's repositories into the combined main, because that main only moves by sync. That can take minutes. If a repository fails to sync, the remote is not fetched — a half-refreshed main would look current when it is not — and the command says which repository failed and why. Because the sync rewrites the combined main, it needs edit access to the project, as Sync now in Settings does; with view access only, the command says so and changes nothing.
• The same fetch is available as repave fetch in the terminal.

/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.

Making a codebase repavable

Your codebase is ready for Repave once Repave can drive it: run its BDD suite, start it in dev mode and for UAT, measure its unit tests, render its Storybook, and read its design system and agent instructions. Repave has a setup job for each of these, started from the project's pages. These commands do the same work in your session, where you can see and fix it, and then submit it.

How a submission works. Each command writes its files and proves them here — runs the suite, starts the stack, renders the story. Then repave setup submit hands the files to Repave, which runs that step's own setup job on them with no agent: the same checks it runs on a file it wrote itself, the same landing on your base branch (a pull request when your project lands platform changes that way), and the same record. So a step done here shows in Repave exactly as if Repave had done it — on the Settings, UAT and Prototypes pages, and in every check that waits for it.

• Repave's checks decide, not the session's. If Repave refuses a submission, nothing lands, and the command shows Repave's reason and fixes it.
• Nothing is committed in your checkout. The files land on the base branch; run /repave:commit to put them on your feature branch too, if it needs them before its next merge from the base.
• Submitting needs a Repave IDE session. In any other checkout the commands still write and check the files, and say they were not submitted.
• repave setup status lists each step and where it stands: configured, missing, running, landing (waiting for its pull request to merge) or failed, with the reason. A step that does not apply says why — a codebase Repave scaffolded came with its dev configuration, BDD runner and test suites, and UAT applies to web apps only.

/repave:make-repavable

/repave:make-repavable

Runs every step your codebase still needs, and nothing that is already done: dev configuration, BDD runner, unit-test suites, UAT configuration, design system, Storybook, agent instructions, then seed data. Each step is proved and submitted before the next starts.

• It asks nothing before it starts. A step that is configured, or that does not apply, is skipped. To redo one, run its own command.
• A failed step stops only what depends on it. Storybook and the seed data wait for the dev configuration; everything else carries on.
• It shows you the status table before it starts, and ends with one line of where Repave has it all — what landed, what is waiting for a pull request to merge, and what failed, with Repave's reason — then the table again.
• The files each step submits are also left uncommitted in your checkout. /repave:commit puts them on your branch too.

/repave:dev-config

/repave:dev-config

Writes prototype-dev.config.sh: how this app installs its dependencies, prepares its database and starts each part in dev mode. It is the file the target-stack prototype preview and /repave:dev-start start from. It follows the same rules as the platform's Generate the dev configuration, so a file written here runs as a preview too.

• An existing file is repaired, not replaced. What is right in it is kept.
• It runs the checks Repave runs on a generated file before submitting: valid shell, a frontend to start, a database compose file that exists, no docker calls, and no page addresses built from the browser's origin. A file that still fails is reported with the reasons, never as done. The preview checks the compose file's own settings again when it starts.
• It submits the file, and once it lands every feature branch cut from the base starts with it, and Repave's previews and implementation agents run from it. A downloaded toolchain beside it is kept out of git by scripts/prototype-dev/.gitignore.
• It asks before starting the app. Answer yes and it runs /repave:dev-start.
• The check needs Node.js.

/repave:bdd-config

/repave:bdd-config

Writes the BDD harness for a codebase you provided: the test runner Repave calls to run your BDD suite, and the Cucumber project and support files it drives. It builds what your codebase needs — Repave's own runner with app and database providers for an npm app at the root, or a runner of the project's own when the tests live elsewhere, such as beside a .NET solution or in a combined workspace's shared test folder.

• The runner goes at the path in your project's settings (the BDD test script). If it needs to live somewhere else, change that setting first.
• An existing harness is repaired, not replaced. A project Repave scaffolded already has one, and only a broken part of it is fixed.
• It proves the harness by running your suite once through the runner, and fixes it until the run works: the report is written, and any failure is a scenario failing, not the harness. It stops after three attempts and shows you the log. If this environment cannot run the suite — no Docker, no access to your package registry — it says so instead of changing a harness that is not at fault.
• It submits the harness, and every feature's BDD runs use it once it lands.

/repave:unit-test-config

/repave:unit-test-config

Works out how your codebase runs its unit tests, and makes each test suite write a coverage report Repave can read — Istanbul or LCOV for JavaScript frontends, Cobertura for .NET and Python, JaCoCo for Java and Kotlin.

• It changes only how coverage is reported, never your tests or your product code. It counts every source file, not only the ones a test touched, and removes a coverage threshold your tool enforces itself — Repave applies the project's own.
• It runs every suite and checks the report appears. The tests do not have to pass.
• Repave runs every suite again when you submit, and saves the configuration only if every one of them can be measured. Until it is saved, implementation that needs unit tests waits.
• A codebase with no unit tests is recorded as such: the step reads "does not apply — this codebase has no unit tests yet", and /repave:make-repavable skips it until you add some.

/repave:uat-config

/repave:uat-config

Writes the UAT configuration: uat-project.config.sh, the app's and the database's compose files, the Dockerfiles under docker/uat/ and any helper scripts. Start-UAT.sh and Stop-UAT.sh are Repave's own and are left as they are.

• It proves the configuration by starting it: the files pass bash -n and docker compose config, Start-UAT.sh brings the stack up, every readiness address answers, and Stop-UAT.sh takes it down. It stops after three attempts and shows you what failed.
• It asks before stopping a UAT stack that is already running in your session.
• When you submit, Repave starts the stack itself. Once that passes, every UAT environment — Main and each feature's — starts from this configuration.

/repave:design-discover

/repave:design-discover

Writes DESIGN.md and updates the stylesheet that encodes the same design tokens. It takes the look from your app's own screens when it has them, from the legacy app otherwise, and asks you to describe it when neither has one.

• It checks the two agree: every token in DESIGN.md is in the stylesheet with the same value, and the reverse.
• When you submit, Repave saves it as the project's design system — the previous one is kept in its history — and prototype and implementation agents design to it.

/repave:setup-storybook

/repave:setup-storybook

Sets up Storybook in your frontend the way Storybook prototypes need it: the right Storybook for your framework, Repave's helpers, a smoke story, and the dev configuration's Storybook start. It applies when your project's prototype mode is Storybook, and needs the dev configuration first.

• It leaves your project as it was: your tests, type check and build give the same results after setup as before, and every dependency it adds is pinned to an exact version.
• It proves the smoke story renders in the Repave Browser.
• When you submit, Repave runs its own Storybook checks — the story renders without reaching the network, and your project's results are unchanged — and once it lands, features can generate Storybook prototypes.

/repave:claude-md

/repave:claude-md

Writes or refreshes this codebase's agent instructions file — the instructions every agent working in it reads first — from Repave's template, customized to what your codebase really holds.

• The template's rules are kept word for word; only the description of the app and its folder structure are written for your codebase. What you added yourself is kept.
• When you submit, Repave saves it as the project's agent instructions for the modernized codebase, the same ones Project settings shows.

/repave:seed-database

/repave:seed-database

Writes the seed that fills your dev database with realistic sample data, in your app's own convention — Prisma, Knex, SQL or what it already has.

• It runs the seed twice against your dev database, and checks the second run leaves the same rows as the first. It asks before starting the app if the database is not running.
• When you submit, Repave lands the seed script; it does not run it. For UAT test data, use /repave:gen-test-data.

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.
legacy-parity	Finding anything the legacy feature had that the scenarios, the prototype or the code lost, and where it was lost.
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.
storybook-setup	Setting up or extending Storybook in a React, Vue 3 or Angular frontend so prototypes can be stories, and writing stories that render without the network.
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.
bdd-config-writing	Writing or repairing the BDD test runner and its support files: what Repave reads from a run, the two shapes a harness takes, and the mistakes that stop a run reporting.

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.
prototype-dev-config-writing	Writing or repairing prototype-dev.config.sh, the file a prototype preview and dev mode start from: what it must define, and the mistakes that stop a preview starting.
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.

Setting up a codebase

Skill	Covers
uat-config-writing	Writing or repairing the UAT configuration: what Start-UAT.sh reads, running several environments at once against one database server, the readiness addresses, a database per environment, and committed seed data.
unit-test-config-writing	Making each unit-test suite write a coverage report Repave can read, per stack, and the suite list Repave verifies.
claude-md-writing	Writing the agent instructions file for each part of the project from Repave's template: what stays word for word and what is written for your codebase.
seed-data-writing	Writing an idempotent seed that fills the dev database with realistic sample data, in the app's own convention.

Working in a project

Skill	Covers
repave-cli-usage	The Repave CLI commands agents use to read and write project data.
feature-labels	Finding a feature's labels and applying what each key's description says, such as a naming convention, the same way in every file.
efficient-code-reading	Searching and reading a codebase without wasting time or context.
git-fetch	Bringing origin/* up to date through Repave with repave fetch — a checkout holds no credential for the remote, so git fetch cannot. Also what /repave:git-fetch runs.
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.