From your first pair to a team of your own

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

rig send dev-owner@first-project '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 owner asks the checker:

rig send dev-check@first-project 'Please try dark mode across the app and send findings directly to me.'

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

From: dev-owner@first-project
To: dev-check@first-project
Please try dark mode across the app and send findings directly to me.

The checker replies to dev-owner@first-project with its findings. The owner 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 checker for its answer yourself.

The owner 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 owner choose a useful division of work. Here, the owner takes coordination, a new builder implements, the existing checker keeps QA, and a new reviewer examines the code independently. Agree the added capacity and model cost before growing the team.

The owner inspects the running team:

rig ps --json
rig ps --nodes --rig first-project --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 owner sets. With unused member names builder and review in the existing dev pod, it runs:

rig grow "$RIG_ID" builder review \
  --pod dev --runtime codex --cwd "$PROJECT_ROOT"
rig ps --nodes --rig first-project --json

This is the expanded version of the rig grow operation in the demo, with the repository and runtime selected explicitly. It adds seats to the running rig. It doesn't copy the owner's conversation into them or give them a job just because they're named builder and review.

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

To watch the four seats together:

rig terminal status
rig terminal open first-project

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 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-BUILDER.md under the project's .openrig/factory/ directory, including the actual slice path, the builder's file or worktree boundary and the next check.

rig queue create --id theme-001 --destination dev-builder@first-project \
  --body-file "$PROJECT_ROOT/.openrig/factory/TASK-BUILDER.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 builder 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 builder's own terminal:

rig send dev-check@first-project 'What did your earlier testing uncover that needs special attention?'

The checker answers directly to the builder:

From: dev-check@first-project
To: dev-builder@first-project
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 builder 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 builder 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 builder has reached the end of its implementation task. QA now needs to own the next step, so the builder uses a handoff, with a request that identifies the candidate, its spec and the case the checker called out:

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

The builder 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 other specialist:

rig queue create --id theme-review --destination dev-review@first-project \
  --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 builder 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-check@first-project}
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-check@first-project \
  --interval-seconds 1800 \
  --registered-by dev-owner@first-project

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 builder is waiting on another queue item, it can park its own work 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