Build from Claude

The dashboard's build conversation is metered: each round runs on Levain's models and bills your credits. If you already pay for Claude, you can do the same work in your own session instead and only pay for the verification pass at the end.

The trade is deliberate. Iteration moves to your machine; the checks that decide whether a version is fit to publish stay on ours. Passing locally is necessary, never sufficient.

SetupCopy Anchor Link

Install the plugin, which teaches Claude how Levain recipes work:

/plugin marketplace add levainlabs/skills
/plugin install levain

Connect the Levain MCP server in your client (see MCP). It signs you in through your browser, so there's no API key to create or store.

Then install the toolchain and sign in:

uv tool install levain-cli
levain login

levain login prints a URL and a short code. Open it, approve, and the CLI holds the session from then on. Install it as a tool rather than running it through uvx — git calls it by name, so it has to be on your PATH.

The loopCopy Anchor Link

Ask Claude to change an agent and the skill takes over. What it does, so you know what to expect:

1. Forks a draft. Published versions are immutable; every change starts as a new draft.
2. Clones the recipe. The CLI acts as git's credential helper and mints a credential scoped to that one repository, good for about an hour. Nothing is written to .git/config.
3. Edits the recipe — the graph.tla spec, the Python behind each node, and SPEC.md.
4. Checks locally with levain validate-package ., which validates the spec, model-checks the graph for unreachable nodes and loops that never terminate, and regenerates the typed state.
5. Pushes, then verifies. The platform re-runs the checks and an independent review against the exact commit you pushed, and records the verdict.
6. Publishes once that verdict is green.

You can drive any step yourself. The CLI and the API are the same ones the skill uses.

Review threadsCopy Anchor Link

Verification doesn't just return a verdict. When the reviewer objects, it opens threads on the draft, each anchored to the code it's about. The skill pulls them into your session, so the fix loop stays where you're working:

1. Read the threads. Each carries the reviewer's comment and the lines it points at.
2. Fix, or answer. Edit and push when the reviewer is right. Reply on the thread when the code is right and the context was missing — and put that context in SPEC.md, where the next pass will see it.
3. Verify again. The next pass reviews the commit you pushed, re-reads the open threads, and resolves the ones it judges settled.

Threads belong to the version, not to your session. Close Claude mid-review and the same threads are there tomorrow — in your next session or in the dashboard, which shows the same state.

What the review readsCopy Anchor Link

The reviewer sees your diff and SPEC.md. It does not see your conversation with Claude.

That makes SPEC.md the place to record decisions, especially the ones that look odd without context: an unusual model on a node, a step kept deliberately simple, a suggestion you considered and rejected. Written down, a choice reads as intent. Left out, it reads as an oversight and comes back as a review comment.

Marking a comment resolved doesn't settle it. The next verification pass judges the code as it stands.

PublishCopy Anchor Link

Once the verdict is green, ask Claude to publish, or publish from the dashboard — both act on the same draft. The verdict is recorded against the exact commit it reviewed, so pushing anything after it means verifying again before you can publish.

Publishing makes the version immutable and live in this workspace. That's the whole story for an agent that only serves one workspace.

Organization agentsCopy Anchor Link

An agent in the org registry goes through the same loop. Address it as org:<slug> — "fork a draft of org:support-triage" — and the skill forks, clones, verifies and publishes it through the registry instead of a workspace. Publishing makes the version every adopting workspace without a pin runs next, so treat the verdict as the release gate it is; pin workspaces first to stage the rollout. Organization admins only.

To get a workspace agent into the registry in the first place, ask Claude to promote it: its active version becomes the org agent's first version, and the workspace copy keeps living where it is. See Fleet Agents.

What stays on the platformCopy Anchor Link

• Verification decides. A version publishes on the platform's verdict, not your local run.
• Published versions are read-only. Pushing to one is refused; fork a draft instead.
• Integrations still gate publishing. A node that calls an integration the agent isn't attached to blocks the publish, same as in the dashboard.
• Runs are unchanged. Where an agent runs, what it costs, and how it's isolated are the same whichever way you authored it.

Working in the dashboard insteadCopy Anchor Link

Nothing here replaces the Recipes tab. Both edit the same versions, so you can start a draft in the dashboard, finish it from Claude, and publish from either. Use the dashboard when you want Levain to do the authoring; use this when you'd rather drive.

NextCopy Anchor Link

• The Quickstart provisions a customer workspace and runs an agent inside it — the loop your published versions feed.
• Recipes covers authoring in the dashboard and the shape of a recipe.
• MCP lists the tools the skill uses.
• Authentication covers API keys, for automation that runs outside a Claude session.