Project settings

Settings are per project. This page covers what a project owner changes in the normal course of work; the deployment-level configuration behind them — registries, gateways, credentials on the host — belongs to whoever installed the platform, and is covered in Install with Docker Compose.

Controls only an owner can use say so, rather than failing when you click them.

How work lands: merge mode

The single most consequential setting.

• DIRECT — feature branches merge into the project's integration branch. A merge runs every scenario in the project twice: on the feature branch before it merges, and on the integration branch after. Skip the second full test run when nothing changed, under Direct, skips the second run when the merged code is exactly the code that just passed. Anything that changes the code in between, such as new commits on the integration branch, still runs the full suite. Off by default.
• PR mode — feature branches become pull requests against your own base branch, tracked in the Pull Requests view. Repave never writes to your base branch itself. Configuration it generates — BDD and UAT test configuration, preview dev configuration, sample data seeds and the design system — arrives as a pull request of its own, from a repave-platform/ branch, and the job says which one it opened. In direct mode the preview dev configuration is committed to your integration branch, so every new feature branch starts with it. A feature's BDD run needs the BDD configuration, so until that pull request has merged the run does not start, and says which pull request to merge.

An existing project can be migrated from DIRECT to PR mode. A feature merged before the switch says which branch it merged into, such as Merged to repave branch, until Repave finds its work on your base branch. From then on it reads Merged to main branch (or whichever base branch you set). Repave checks this itself, even for features whose branch was deleted when they merged. A feature whose work has not reached your base branch keeps naming the branch it merged into, and its page says the work is still to land.

Implementation gates

What has to be true before an implementation is accepted. Each is a switch, and together they decide how much the platform insists on before it calls a feature done:

• unit tests, and a coverage threshold
• a false-positive review of passing unit tests — off by default, and worth turning on where green tests are not trusted
• UI, API and database-schema checks
• scenario-drift detection
• implementation planning, and scenario-by-scenario implementation
• a maximum number of review cycles

Numeric settings are bounded, so a value that would make no sense is refused at the point you set it.

Models and agents

Agent Defaults is a table with one row per agent the product runs. Per agent you can set:

• the model it runs with, and the advisor model that reviews its work
• its timeout
• how long its prompt cache lives, and what that has cost
• whether it gets a browser
• what memory it captures, uses and is given
• its budget: the most one run of that agent may spend. Empty means no limit of its own. It cannot be more than the maximum per run your administrator sets, and it is read-only when your administrator does not let users set budgets (see Budgets).

To set one of the on/off columns (Browser, Graphify, Capture, Tools, Inject) for every agent at once, use the checkbox in that column's heading. It ticks every agent, or clears every agent when they are all ticked, and shows a dash when they disagree. Agents that are switched off elsewhere in settings are left as they are, and Inject is only ticked for agents that have Tools.

A per-run model an operator picks for one launch overrides the row for that run only.

An agent's model is one of three Claude tiers, and Elite model name, Pro model name and Speed model name say which model each tier runs. A new project starts on Claude Opus 5.5, Claude Sonnet 5.5 and Claude Haiku 5.5; an existing project keeps the models it has until you change them. Claude Haiku 5.5 costs five times as much per token for a turn whose prompt is over 100,000 tokens, cached tokens included, so a Speed agent that reads a lot uses up its budget faster than its short turns suggest.

Changing an agent's model, or which advisor the project uses, turns off any advisor that can no longer advise that agent. When you change the advisor, the page also tells you how many agents it turned off. If you undo the change before you save, those advisors come back. An advisor you picked yourself in the meantime is kept.

Agents can ask you and hear from you, under the table, is on by default: every agent can ask you questions, wait for your approval of commands its safety check hands back, and read what you type in its chat (see Talking to an agent while it runs). Turn it off and agents run without stopping, as before. The change applies to runs started after you save.

Always-allowed commands, below it, lists the commands someone chose Always allow for when an agent asked, with who added each and when. The agent runs those without asking. Remove takes a command off the list for the next run, after which the agent asks again.

Skills

Skills are the written instructions Repave's agents and Repave IDE sessions follow to do each kind of work — how a feature file is written, how step definitions are bound, how lint is resolved. The Skills tab lists every one, in two groups:

• Agents and developers — every agent run is offered these, and developers can use them in the Repave IDE.
• Developers — commands a developer runs in the Repave IDE, such as committing or starting UAT.

A change here applies to this project only. Every other project keeps Repave's version, and a project nobody has edited follows each Repave release as it always has.

Choose a skill to read it. Each skill has two copies, Claude Code and Codex, because the Repave IDE runs either assistant; agent runs use the Claude Code copy. Each copy is edited and versioned on its own.

A skill is a folder: its SKILL.md and any files beside it — reference notes an agent reads, scripts it runs, schemas. The editor shows the folder beside the text, and every file in it can be opened and edited.

Editing a skill

Edit the text in place and choose Save changes. You can edit in Fields — the description, which is what an agent reads when deciding whether to load the skill, and the instructions — or in SKILL.md, the whole file. Switch between them at any time without losing what you typed. A skill's name and audience cannot be changed, because agents' instructions refer to skills by name.

Files. In the editor's file list, New file adds a file at the path you type, such as references/notes.md — folders are made as you name them. Upload adds a folder, or files and .zip archives; loose files go into the folder of the file you have open. Each file and folder has a ⋯ menu to Rename it (a folder takes everything in it along) and, for a folder, Remove folder. Remove file is above an open file. A file that starts with #! is a script agents and developers can run. Skills hold text files only, up to 1 MB in all; a file that is not text is refused by name. Every change to the files is saved with Save changes, as one version with the rest of the skill.

Add a note if you like; it is shown in the history beside your version.

Your version reaches this project's agent runs and Repave IDE sessions that start after you save. Agents already running keep the text they started with. Choosing another skill with unsaved changes asks before discarding them.

If someone else changed the skill after you opened it, saving is refused so neither change is lost silently: choose Reload to see theirs.

Adding a skill of your own

Add skill, at the top of the list, adds a skill to this project only. Give it a name (lowercase letters, numbers and hyphens), who uses it, a description and instructions:

• Agents and developers — offered to every agent run in this project, which loads it when its description fits the work, so write the description as what the skill is for and when to use it. Developers can use it in the Repave IDE too.
• Developers — a command developers run in this project's Repave IDE sessions: /repave:<name> in Claude Code, /<name> in Codex.

To bring a skill you already have — a folder with a SKILL.md, written for Claude Code elsewhere — choose Start from a folder and pick the folder or a .zip of it: the form is filled from its SKILL.md, and its other files are added with it. Adding makes both the Claude Code and the Codex copy; edit either afterwards. The name and who uses it can't be changed once it is added.

Your own skills are marked ADDED in the list. Remove skill removes one: it is listed under Removed, no agent or session gets it, and Restore skill brings it back with its history. Repave's own skills can't be removed.

If a later Repave release ships a skill with the same name as one you added, yours stays in use and the skill says so, with Compare and Use Repave's version.

History

Every version of a copy this project can use is kept — the whole folder, not only SKILL.md: the ones each Repave release ships, labelled with the release, and every one saved in this project, labelled with who saved it, when, and their note. Versions saved in other projects are not shown. History lists them, newest first, with In use on the one this project's agents get. Choose a version to see Changes from the version in use, file by file, or its Full text, and Use this version to put it back in use. Nothing is ever deleted while the project exists, so this can always be undone the same way.

When Repave updates a skill you edited

Upgrading does not replace your edits. When a release changes a skill whose copy is on this project's version, that version stays in use, the skill is marked in the list, and the copy says which release changed it. Compare shows what the release changed; Use Repave's version puts it in use.

The one exception is a release that changes who a skill is for — turning a developer command into a skill every agent is offered, or the reverse. Your version was written for the old audience, so Repave's version goes into use and yours stays in the history. For the same reason, Use this version refuses a version written for a different audience than the release has the skill for.

A copy on one of Repave's versions — including an older one you went back to — follows Repave's releases: the next release that changes it puts the new text in use. Going back to an earlier release does the same in reverse: copies that follow Repave's releases return to that release's text, and copies on this project's version keep it.

On an installation that runs agents as Kubernetes pods, those agent runs use the skills built into the release, not edited versions.

Providers

How agent calls reach a model. A new project defaults to direct dispatch; the routed modes are available where your deployment enables them:

• Anthropic API directly
• Vertex AI, running Claude models in your own GCP project
• Gemini, and other providers, through the translation gateway

A project with no key of its own uses the one your administrator set in the Admin portal; its field reads Using organization key. Enter a key here to use a different one for this project.

Provider and memory smoke tests are on this page: run them after changing anything here rather than finding out on your next implementation.

Integrations

• GitHub / Azure DevOps — a personal access token, repository creation, and branch pushes. The link maintains itself: it pushes on creation, syncs both ways, and pushes again at merge time.
• Team Foundation Server — including trusting a private certificate authority, or skipping TLS verification for one connection.
• Source repositories — for a project combining several, managed here.
• Package registries — where agent jobs, test containers and scaffolding resolve dependencies from. Set these for an air-gapped or proxied network.
• Prototypes — Prototype Mode, where each feature's prototype comes from: HTML, Figma, or Storybook (the project's own components, with a story per To-Be state), and whether HTML and Figma designs are also built on your own stack. Choosing Storybook sets it up in your codebase straight away and shows how that is going on this card. See UI prototypes.

The code index

Two checkboxes decide whether the code index runs. The page reports what state the index is in and lets you rebuild it. It is what lets agents answer questions about the codebase without reading all of it, so a stale or missing index shows up as agents that seem not to know their way around.

Repave IDE sessions

The context window a session's assistant runs with, and how it signs in. See Repave IDE.

A session keeps the sign-in it started with, so a save that changes it — the sign-in mode, or the project's API key or other credential the sessions use — stops the sessions open for this project. Before saving, Repave asks Stop running Repave IDE sessions? and says how many are open. Stop and save saves and stops them: files on disk are kept, but running terminals and processes end. Cancel saves nothing. A save that changes none of these never asks, and if another session opens while you decide, you are asked again with the new count.

Team

Who can see and change this project. Editors can do the work; viewers can read it. Some controls are owner-only.

Inviting someone gives you a link to send them. If your administrator has set up email in the Admin portal, the invitation is also emailed, and the dialog says whether it was sent. The link opens a page where the invitee signs in, or creates an account with the invited address, and accepts. An invitation expires after 7 days.