From your first pair to a team of your own

To ask for a change, type into the builder’s conversation or send it from your terminal:

rig send dev-build@starter 'Add dark mode to this app.'

Set the working agreement once: which repository they're changing, what access they have, and what should wait for you. In this walkthrough, changes stay local and publication is outside the task. You don't need to repeat the internal review steps in every request.

Let the agents talk

From its own terminal, the builder asks the reviewer:

rig send dev-review@starter 'Please try dark mode across the app and send findings directly to me.'

The reviewer sees who sent the message and who it is addressed to:

From: dev-build@starter
To: dev-review@starter
Please try dark mode across the app and send findings directly to me.

The reviewer replies to dev-build@starter with its findings. The builder handles any repair and comes back with a result you can try. You aren't copying messages between their terminals, and you don't have to ask the reviewer for its answer yourself.

The builder can use the Software Factory recipe to organize that effort. The recipe is guidance your agent loads, not a separate service or a team that starts automatically:

rig context get skills/core/openrig-software-factory/SKILL.md

It helps the builder choose a useful division of work. Here, the builder takes coordination, a new designer designs and builds the theme editor, a new QA seat tries the user paths, and the existing reviewer keeps examining the code independently. Agree the added capacity and model cost before growing the team.

The builder inspects the running team:

rig ps --json
rig ps --nodes --rig starter --json

It sets RIG_ID to the team's rigId from that output and PROJECT_ROOT to your repository's absolute path. These are shell variables the builder sets. With unused member names design and qa in the existing dev pod, it runs:

rig grow "$RIG_ID" design qa \
  --pod dev --runtime codex --cwd "$PROJECT_ROOT"
rig ps --nodes --rig starter --json

This is the expanded version of the rig grow operation in the demo, with the repository and runtime selected explicitly. To add Claude Code seats instead, use --runtime claude-code. It adds seats to the running rig. It doesn't copy the builder's conversation into them or give them a job just because they're named design and qa.

The builder sends each new colleague its responsibility and relevant project sources, then gets a response before assigning work. The reviewer stays on the team with the knowledge it has already built up.

To watch the four seats together:

rig terminal status
rig terminal open starter

Open the view after the new seats are ready, then use your terminal provider's split controls for a two-by-two arrangement. rig grow changes the team; the terminal view is how you look at it. rig terminal open has no layout flag.

The coordinator, dev-build, creates the mission and first slice in the selected project:

mkdir -p "$PROJECT_ROOT/missions"
rig scope --workspace "$PROJECT_ROOT" mission create custom-themes \
  --intent 'Let users create, share and sync custom themes.'
rig scope --workspace "$PROJECT_ROOT" slice create custom-themes theme-editor \
  --intent 'Create and save a custom theme.'

These are the same scaffold operations shown in the demo, with an explicit project path. Creating missions/ first is the workaround for the current first-mission path issue. Inspect the paths returned by the commands, then write the first slice's SPEC.md. The scaffold creates a place for the plan; the agent supplies its meaning.

A short spec can make the boundary clear:

Intent: create and save themes.
Out of this slice: sharing and sync.

The coordinator adds the project-specific details and how the result will be checked. It then writes TASK-DESIGN.md under the project's .openrig/factory/ directory, including the actual slice path, the designer's file or worktree boundary and the next check.

rig queue create --id theme-001 --destination dev-design@starter \
  --body-file "$PROJECT_ROOT/.openrig/factory/TASK-DESIGN.md" \
  --summary 'Build the theme-editor slice from its spec'

theme-001 is the example ID used in the demo. Choose an unused ID for your own work. The designer receives the queue notification, then reads and claims the assignment in its own seat:

rig queue show theme-001 --full
rig queue claim theme-001

From the designer's own terminal:

rig send dev-review@starter 'What did your earlier testing uncover that needs special attention?'

The reviewer answers directly to the designer:

From: dev-review@starter
To: dev-design@starter
Settings was the exception. It needed separate testing and a fix;
the other screens followed the shared theme.

Use the reply in the work and in what the designer returns for QA. Ask the relevant colleague from your own seat; you don't need a new queue item for a question.

Keep what the team learns

The designer needs the slice spec and code. The reviewer needs the candidate and the project's conventions. The coordinator needs enough of the whole picture to decide what happens next.

Keep shared decisions in project files as well as in the conversations. Those files give agents something to recover from when a session changes. As the sources grow, rig context get world-example gives your agent a starting template for a project context pack. This is part of building your own configuration layer around the lean core.

The designer has reached the end of its implementation task. QA now needs to own the next step, so the designer uses a handoff, with a request that identifies the candidate, its spec and the case the reviewer called out:

rig queue handoff theme-001 --to dev-qa@starter \
  --body-file "$PROJECT_ROOT/.openrig/factory/REVIEW-REQUEST.md"

The designer writes that request file before handing off. The handoff returns a successor task for QA. In the demo it is shown as theme-qa; in your project, use the actual returned ID. QA reads and claims that successor in its own terminal:

rig queue show <qa-id> --full
rig queue claim <qa-id>

QA tries the user paths against the spec. Alongside that, the coordinator assigns code review to the reviewer:

rig queue create --id theme-review --destination dev-review@starter \
  --body-file "$PROJECT_ROOT/.openrig/factory/CODE-REVIEW-REQUEST.md" \
  --summary 'Review the theme-editor implementation against its spec'

The coordinator writes the code-review request against the same candidate. As with theme-001, choose an unused ID for your project. The reviewer reads and claims it:

rig queue show theme-review --full
rig queue claim theme-review

These are two different questions. QA asks whether the result does what the spec requires. The reviewer examines how the implementation fits the codebase. Both return their findings to the coordinator and record their results on the work. If something needs repair, it goes back to the designer and the affected check runs again.

You can ask the coordinator:

I’m going to bed. Can you keep working on this while I’m away?

An agent works during its active turn. When that turn ends, it is idle: it isn't thinking in the background. A new message or wake can bring its attention back to unfinished work.

In the demo, the coordinator writes qa-wake.yaml:

policy: periodic-reminder
target: {session: dev-qa@starter}
message: >-
  Check your queue. Continue unfinished work
  or hand it to its next owner.

It registers the reminder from the directory containing that file:

rig watchdog register --spec qa-wake.yaml \
  --policy periodic-reminder \
  --target-session dev-qa@starter \
  --interval-seconds 1800 \
  --registered-by dev-build@starter

This sends the configured message every 30 minutes. The timer doesn't detect idle agents or unfinished work; QA checks its queue after receiving the reminder. It reads its owned task and resumes from the recorded state. Use the returned QA task ID in your project:

rig queue show <qa-id> --full

Choose an interval that fits the work and agreed spending limits. Stop the recurring reminder when it is no longer useful, using the job ID returned by registration:

rig watchdog stop <job-id> --reason "Overnight work finished"

When work has a specific blocker

If the designer is waiting on another queue item, it can mark its task as waiting on that dependency. From the seat that owns the waiting task:

rig queue block <owned-id> --on <blocker-id> \
  --continuation 'Read the dependency result, then resume this slice.'

Replace both placeholders with actual queue IDs. When that local dependency resolves, OpenRig can return the waiting work to its owner. For an external wait, name the blocker and arrange a reminder when one is useful:

rig queue block <owned-id> --on external:preview-environment \
  --wake-after 2h \
  --continuation 'Check whether the preview environment is available; resume QA if it is.'

That is an example of a real wait, not a timer to add to every task. The continuation tells the returning agent what to do. A wake brings its attention back; it doesn't resolve the dependency or answer a permission prompt.

Agree the work and spending limits before leaving the team running. Agents can keep working overnight or while you're away, and reach out when they need a decision. Delivered wakes can spend tokens, so prefer a dependency resolving over repeated reminders with nothing new to act on.

The coordinator reads the QA successor and the separately assigned review before summarizing. Replace <qa-id> with the actual successor ID, and use your project's review ID:

rig queue show <qa-id> --full
rig queue show theme-review --full