How Camino works.

1. The idea in one minute

A plan is a set of tracks — lines of work that can move at the same time, such as “install”, “pilot” and “lane A”. Each track is a sequence of steps, and every step has four parts: why it exists, what to do, what is true when it is done, and what evidence proves it.

• One step per track. Each track shows exactly one current step. There is no backlog to sort and nothing to choose between.
• No “mark done”. Nowhere — not in the app, the API or Claude Code. You submit what the step produced, and an independent verifier decides whether it counts. The next step opens only on a pass.
• Nothing is rewritten. Every event goes into a history that cannot be edited, and decisions go into a log where a changed mind is a new entry, not an edit.

2. Start a project

1. Sign in with your email (you get a link) or with GitHub.
2. New project → “I have a plan”. Give it a name and upload the plan file, a markdown file in Camino’s plan format (section 13 shows one). Camino checks the whole file before it creates anything; if something is wrong it lists every problem with its line number, and nothing is imported.
3. You land on the project’s overview, with your next step in front of you.

3. The overview

A project opens on its overview, and the overview puts one next step in front of you: the answer to “where was I?” after two weeks away. It is chosen from the current step on each track: one that needs attention first (its check failed, or a blocker is open on it), then one you can work on, then the one you last worked on, then the earliest in the plan. Only a step that is yours or nobody’s is chosen. Its card says what is true when it is done, roughly how long it takes, whether it runs on your computer, and what comes after it; Also open, beneath it, lists the other tracks’ current steps, with whose they are.

Above the greeting, a short notice appears only when something needs you: an open blocker, a channel that missed its bar, changes to the plan waiting for your answer, a kill criterion whose date has passed, catch-up when your code may already do some of the plan, and a plan agreed against its assessment. Beside the next step, Last checked is the latest verdict. Below, Your path shows the plan’s four phases (Shape your idea, Set the foundations, Build your first version, Find your customers), with how many steps each has checked; a plan without phases shows its tracks instead. Recent progress is the last three things that moved.

A step is in exactly one of these states:

Two counts on the path are worth knowing. “N attested” counts the steps in that phase finished on a typed confirmation rather than shown output — the weakest kind of evidence, counted so a phase does not look further along than it is. “N over a failed check” counts overrides (section 5).

The sidebar has your workspace (the overview, your idea, your plan and finding customers) and your record: Evidence, every check newest first, Decisions and History. The project’s name at its top opens a menu to switch projects, start one, see People and open Project settings, where Stop this project is. Your avatar, top right, has the theme, API tokens, Billing and Sign out.

4. Doing a step

Open a step from the overview. Its page says where the step sits (its number in the plan and its phase), its status in plain words, its code (the command line and your coding agent use it), roughly how long it takes, and where its commands run. Then three parts, in this order, each with a one-line heading when the plan gives one:

• Why — what the step is for. You can skip it: everything needed to finish the step is in the Do and the Check.
• Do — exactly what to do. Commands are in boxes with a Copy button; a box marked Copy as prompt is meant to be pasted into your coding agent rather than a terminal. Copy rather than retype: the Do is meant to be run verbatim. Copy a prompt for your coding agent hands it the whole step, if you are not working from Claude Code.
• Check — what is true when it is done, in terms you can see. View the criteria shows what the check looks for, and what it cannot establish. Read them before you start.

Below the parts is the box where you share your evidence (section 5), and under that a row of what else you can do. I’m on this claims the step, so everyone else in the project can see you have it; Put it down releases it. I’m stuck and Propose a change are section 6 and section 8. Ask for help opens the step helper: Explain the Do, line by line explains what each command does and why, and answers follow-ups. It can tell you the step is wrong. It cannot mark it done. Copy a prompt for your own assistant gives you the same question with the whole step in it, to paste into whichever coding assistant or chat you already use, so it runs on that assistant’s plan instead of this site’s model budget. The step’s details (what it depends on, how it was proved, its changes) and its earlier checks are folded at the foot.

5. Evidence and the verifier

Evidence comes in three tiers, most trustworthy first:

Paste it in the box under the Check and press Share it for a check, and the verifier answers. It is a separate model call that sees three things only: the step’s Check, its Result and what you shared. It does not see your chat, your code or the agent that did the work. So paste the real output, from the command you typed to the last line — not a summary of it. The answer is laid out above the box: what the check found, what you shared, what comes next and what the check cannot tell you.

• Passed. The step is done, the next step on its track opens, and anything elsewhere that was waiting on it unblocks. What comes next names the step it opened.
• Needs attention. The check found something to fix. A blocker opens, showing what the step expected beside what the evidence showed; fix it and share fresh evidence, or Work out why with the guide.
• Inconclusive. Nothing changes. The reasons say what was missing; share better evidence.

After a failed check you can Attest anyway, saying what you did and why the check does not apply. That closes the step, and it is recorded as an override and counted on the track for as long as the project exists. Sometimes that is the right call; it is never an invisible one.

Every verdict is a paid call to a model, and the site has a monthly budget for them. If it is used up, your evidence is still recorded, the step waits, and the page says so and when the budget resets. Nothing is passed or failed without being judged.

6. When a step fails, or you are stuck

A step whose check failed has a blocker, and so does one you said you are stuck on: I’m stuck asks what you ran and what it did, and opens one in your own words. Work out the blocker, at the foot of the step, has three ways out:

• Work out why — a conversation that diagnoses the failure from what the step expected and what you observed.
• Resolve — you were wrong and have fixed it. Say what fixed it; then submit again.
• Escalate — the plan was wrong. Correct the step or skip it, with a reason, and the blocker closes with the change on the record.

If a step cannot even be attempted — a credential you do not have, a command that is not installed — say so rather than submitting evidence you expect to fail. From Claude Code that is camino_open_blocker; from a terminal, camino blocked.

7. Sprints: steps that repeat

Most builds repeat a set of steps once per thing — per sprint, per customer, per integration. A plan holds those steps once, as a procedure, and each step that runs the procedure gets its own copy of every stage, with the thing’s name written into the text.

claude
/effort high
/sprint-plan s4-stripe-payments

On the dashboard a stage shows which run it belongs to — Sprint s4-stripe-payments · stage 1 of 5 — and stages move one at a time like any other step.

8. When the plan is wrong

Plans are wrong in small ways all the time, and the fix is part of the record. On any step, Propose a change, at its foot, offers:

• Correct it — edit the Why, Do, Result or Check.
• Skip — the step is not needed. Say why.
• Reopen — a finished step turned out not to be. Its evidence and verdicts stay where they are.

Each asks for a reason and lands in History. To replace the whole plan, use Replace this plan with a new file at the bottom of the Plan page. The old version is kept, not deleted, and anything that belongs to the project rather than the plan file — its distribution channels — moves onto the new version.

9. Decisions, History and People

• Decisions — a log with permanent codes (D-001, D-002…). Record a decision writes one; replacing one supersedes it, and the old entry keeps every word, struck through. Claude Code can record decisions too, so they stop being argued again in the next session.
• History — every event in the project, newest first. Append-only: nothing in it can be edited or removed, including by us.
• People — Invite somebody by email; if they have not signed up, the invite waits and applies when they do. A track can have an owner, and claims show who is on what.

10. Distribute: is anybody coming?

A build that ships to nobody has not finished. Distribute is where you try channels — outreach, communities, a launch — and find out which ones bring anybody.

1. Set your site’s address, so each channel gets a tracked link to it.
2. Add a channel with a bar: for example, 3 sign-ups from its tracked link within 14 days. The bar goes into the decision log before the first post and cannot be changed afterwards — so the result is judged against a bar nobody moved. Not sure which channel? Choose with the coach asks four questions and proposes one, or two if your hours allow; nothing is added until you accept it, and never a third while two are running.
3. Work its activities from the dashboard like any other track, or from Claude Code, where each activity arrives with the channel’s tracked link and its number so far. They are attested: nobody can check that you sent a message, and nobody needs to.
4. Connect your app: your server reports sign-ups and payments to Camino with a signal key, tagged with the link they arrived through. The channel is judged on those numbers, never on one typed into Camino.
5. Connect Stripe and payments arrive by themselves: point a Stripe webhook at the address the page gives you, paste its signing secret, and put the channel’s tag on each checkout. Camino checks Stripe’s signature on every delivery and holds no key to your account. Test payments show the connection works and never count.
6. Cannot connect it yet? Paste a reading on the channel: a screenshot or export from your own analytics or payments tool, filtered to the channel’s tag and dates, and the number it shows. The verifier checks it shows all three, and only then does it count. The card says the number came from a reading, and the screenshot is not kept.
7. A channel that missed its bar says so; stopping it records the numbers in the decision log. One that reached it is the one to put more into.

11. Stopping, and shipping

Stopping is a decision. Stop this project asks which criterion you are invoking and what showed you it was met, then records a “Stopped:” decision, opens a short post-mortem with three questions, and hands out no more work. The steps stay, as a record of what was tried.

Shipping has to be proved. There is no button for it. A project ships when the step marked Milestone: first_payment passes — somebody paid you, and the verifier agreed. With Stripe connected, the first live payment passes it by itself, on Stripe’s signed record rather than a screenshot. Check that your plan has such a step; without one, a project can never ship.

12. Working from Claude Code

Everything above has a way in from Claude Code: what’s next, a step in full, claiming, submitting evidence, saying you are stuck, recording a decision. It still cannot mark anything done. Camino in Claude Code covers setting it up and using it, with Ronda’s sprint loop as the worked example.

13. Writing a plan file

A plan file is markdown. Tracks are ## Track: KEY · Name, steps are ### CODE · Title with a few lines of metadata, and every step has the four parts. A short example:

## Track: web · Web app

Phase: 3

### W01 · Deploy a page that says hello
Depends on: —
Effort: 1
Origin: template

**Why** A deploy that works on day one means every later step is tested where it will run.

**Do**
In the project folder, deploy it:

```bash
vercel --prod
```

It prints the URL of the deployment when it finishes.

**Result** The URL opens a page that says hello.

**Check** (tier: paste)
Paste the URL and the output of curl -sI on it. The evidence must show HTTP 200.

### W02 · Take the first payment
Depends on: W01
Effort: 2
Origin: template
Milestone: first_payment

**Why** …

• Codes are letters then two digits (W01), unique and permanent: evidence and history refer to a step by its code forever.
• Depends on lists codes, from any track, or — for none. A dependency cycle is refused at import, because nothing in it could ever start.
• The Check’s tier is auto, paste or attest, and its text is the rubric. Write it as a test — “the evidence must show HTTP 200” — not a description.
• Phase, on the line under a track’s heading, puts the track in one of the four phases the overview shows: 1 Shape your idea, 2 Set the foundations, 3 Build your first version, 4 Find your customers. Give every track one, or none: a plan without phases shows its tracks instead.
• Effort is how long the step takes, in evenings of about two and a half hours (0.25 is about forty minutes), which the overview turns into a rough time.
• Milestone: first_payment marks the step that ships the project.
• Procedures are ## Procedure: KEY · Name with stages that use {subject}; a step runs one with Runs: KEY and Subject: s4-stripe-payments.

Put explanation around commands, never inside a command block: a Do is pasted into a real terminal, and a comment line there runs.