Today · First run

First run

One screen of questions, then RepoOps builds itself. Everything a machine can work out is already filled in when you arrive. You correct what is wrong, add the two things nobody can detect, and press Build. There is no second screen.

Where to find it

  • Desktop: http://localhost:4000/, then Today → First run in the sidebar.
  • Keyboard: ⌘ K, then type “First run”.
  • API: GET/POST /api/onboarding/intake, POST /api/onboarding/setup/run, GET /api/onboarding/setup

What it does for you

Asks you only what it cannot find out.Your repos, the coding tools you have installed, and what your product is built on are all detected. The two answers no machine can infer are what you are shipping and by when, and those are the two that seed your launch plan.
Checks each step landed before starting the next.A step is not done because a call did not throw. Each one declares what its result has to satisfy, and a step whose result does not satisfy it fails, even when nothing errored. That is the difference between a setup that worked and a setup that finished.
Stops at a failure instead of limping past it.Later steps depend on earlier ones. A run that keeps going after a failure produces a dashboard that looks configured and is not, so the run halts, names the step and the reason, and waits.
Resumes exactly where it stopped.State is written after every step, so a closed window or a killed process does not cost you the work already done. Press Build again and it picks up at the step that failed.

What it will not pretend

A repo whose history nothing has counted shows not counted yet, never 0. A zero beside a repo with two years of work would read as "RepoOps cannot see what I do", and that is the most damaging wrong impression a first run can leave.

Every detected coding tool is offered at the depth RepoOps can actually read it, not at the fact of it being installed. Claude Code carries prompts, tool calls and cost. Cursor carries files and timing but no prompt text, so it is marked blame-only. A tool whose reader has never been verified against a real install is listed unchecked, with the reason, rather than quietly included: a detector pointed at data a tool does not produce never fires, and a scan that never fires looks exactly like a clean machine.

If this build cannot perform a step in the plan, the run is refused before anything happens rather than failing halfway through.

Where your answers go

Your answers are stored on this machine. Your provider key is not among them: it is passed straight to the settings store that already owns provider credentials and is never written into the first-run record, never returned by any read, and never present in the run state that outlives the run.

Configure

Nothing before you start. Every answer is changeable afterwards in Settings, and re-running setup resumes rather than starting over.

Read more

Last updated