Skip to content

Your First Orcho Agent Run

A first Orcho run should be a mono-run: one project, one task, one delivery surface. This keeps the first proof understandable.

The profile for this run is the semantic wrapper around the lifecycle. It says how much planning, review, repair, final acceptance, and evidence this first task should require.

Quickstart walks the setup and the exact orcho run command. This page is the companion view: what happens inside that first run, what task to feed it, and how to judge the result. Run with --profile feature — the full shape (plan, validate, implement, review, repair if needed, final acceptance) is the point of a first run: see the whole protocol once before thinning it down.

For a normal feature-style run, Orcho moves through a lifecycle like this:

task
plan
implement
review
repair, if needed
final acceptance
delivery decision

Each phase writes durable artifacts under the run directory. The terminal output is the strongest way to understand the run as it happens; the run directory is the durable source of truth afterwards.

Pick something small but real:

  • a validation rule;
  • a missing error branch;
  • a focused test addition;
  • a small documentation correction with verification.

Avoid the first-run trap: do not start with a broad refactor or multi-repo feature. You want the lifecycle to be obvious before you add topology.

An Orcho run is not done because a worker produced text. It is done only after the lifecycle reaches a terminal state and the final surfaces agree on what happened.

The important questions are:

  • Did the plan match the requested task?
  • Did the implementation touch the expected files?
  • Did review find blockers?
  • Were required checks run?
  • Did final acceptance approve or reject?
  • Is there a correction or delivery decision pending?

Those answers live in status and evidence:

Terminal window
orcho status
orcho evidence --format md