Docs

The Vinaya process

Working with it

How you, the Principal, use the Vinaya process day to day: three commands in your agent, your rulings, and Studio. The agents do the rest.

Principal
Slash commands
Rulings
Studio

About working with it

You drive the Vinaya process from inside your agent, in Claude Code or Codex. Three commands start the agent roles. You decide at a few fixed points, and you watch everything in Studio.

Run the three commands

  1. 1

    /vinaya architect

    Thinking. The Architect turns product work into one milestone. You decide the parts together.

  2. 2

    /vinaya planner

    Thinking. The Planner writes every task as an Issue an agent can run. You approve the plan.

  3. 3

    /vinaya operator

    Executing. The Operator dispatches the agents, runs the gates, and stops when it needs you.

You do not have to start at the top. Start with the Planner for one feature or one fix. See the guides.

Where you decide

You hold three decisions:

  • Approve the plan. No task is dispatched before you do.
  • Rule when a run pauses for you. A pause names who must act. When it is you, post your ruling with vinaya pr rule. See Pauses and rulings.
  • Merge. Nobody else merges, and the gates must already be green.

Watch it in Studio

Studio is a harness feature that reads the Log. With the Vinaya process it shows every milestone, every task and every review round, live. See Studio.

The commands

These are the commands you run yourself in the Vinaya process. The rest are run by the Operator and the agents.

studio

$ vinaya studio

Launch Vinaya Studio — runs the Studio dev app when its source (apps/vinaya-studio/web) is in a checkout above the current directory; a published install launches its bundled standalone server instead

Resolution happens in this order: a workspace checkout carrying apps/vinaya-studio/web (Studio's source, which lives in the attalabs monorepo — not this repository) runs the dev app directly; a published install's studio-standalone/ bundle (fetched from attalabs' release artifact at publish time, see scripts/bundle-studio.ts) runs that bundled server; anything else — a publish that shipped without the bundle — gets an explicit refusal and exit 1 rather than a silent no-op.

Every published @attalabs/vinaya build ships the studio-standalone/ bundle: prepack fetches attalabs’ latest CI-built standalone Studio artifact and assembles it into the tarball before publish.

--port <n>Bind this exact port. Without the flag the default is unchanged — 3008, falling back to 3108 when it is taken. With it there is no fallback: a taken port is refused, so you always know which server answered. Accepts `--port 3208` and `--port=3208`. Applies to a published install; in a workspace checkout Studio's own dev script owns the port and the flag is refused.

pr rule

$ vinaya pr rule

Post a Principal ruling on a PR, marked and versioned — never mistaken for a review verdict

Refuses before posting when the file's first line reads as an escalation (ESCALATE:), or when the file carries verdict grammar anywhere extractCodeReviewVerdict/extractSecurityReviewVerdict would treat as a candidate — a VERDICT: line past the extractor's own first-five-line window still counts, since the whole-body candidate test is what disqualifies the file, not merely a clean read.

Marker numbers (<!-- aeg:principal:ruling:<pr>-<k> -->) are counted on the forge at post time from gh pr view --json comments, never derived from a local file — two rulings racing to the same number are a known, undocumented-lock case.

--filePath to the ruling file to post as a PR comment
--jsonEnveloped JSON output (schema: 1)

What's next