Plan with the strongest model, implement with smaller ones

The best use of my strongest coding model is deciding what smaller models should build. I keep it close to investigation and review because a wrong assumption can spread through several parallel changes.

With /orchestrate, I work through investigation, a concrete plan, authorization, implementation, and review. The LinkedIn post gives the short version. Here I follow what moves between the main model and its workers.

Install the workflow

Both commands install /orchestrate and its six companion skills: /scope-and-plan, /plan-format, /model-tiers, /implement, /verify, and /commit-message.

Choose the command for your platform. The installer detects your coding agents and leaves existing agent instructions and terminal settings unchanged.

macOS or Linux:

curl -fsSL https://r1cco.com/skills/orchestrate | bash

Windows with PowerShell 7:

irm https://r1cco.com/skills/orchestrate.ps1 | iex

Then ask your coding agent to use /orchestrate for a code change.

Investigate

When I run /orchestrate, it loads /scope-and-plan. Readers investigate separate parts of the codebase and return claims with file:line anchors.

I check each return against its brief and the cited code. I drop claims that are empty, off task, unsupported by the anchor, or point to code that doesn't exist.

After checking every return, I remove duplicate findings and synthesize Paths, Facts, Gaps, and a provisional Approach. Waiting for every reader lets me compare overlapping evidence before deciding what the code shows.

A reader tries to answer a question from one part of the code, so it can miss a conflict with another finding. A fresh, read-only skeptic checks the verified anchors to challenge those findings rather than gather more evidence.

If the skeptic refutes a fact, I move it to Gaps with the reason. That keeps an untested claim from quietly becoming a decision in the plan.

Make a reviewable plan

/plan-format turns the approach into ordered before-and-after diffs. Its Verify section names the narrowest check that would catch a mistake.

Small new files appear in full; longer changes can use a representative excerpt. The import hunk below is illustrative, not a change from a specific run.

Seeing the lines helps me judge the scope before implementation starts. An open question stays beside the plan item it blocks instead of hiding inside a broad summary.

/scope-and-plan enters the harness's plan or approval mode before presenting the plan. I reuse authorization already given for the same scope and actions.

I wait for authorization when it's missing and start implementation only when the harness permits it. Existing authorization does not override an enforced planning mode.

Set worker boundaries

After authorization, /implement groups changes by the files they touch. Independent groups with disjoint paths can start together. A dependent group waits for me to accept its upstream result.

/model-tiers reads role preferences from tiers.yml, then checks which agent types, models, and effort controls the harness supports. If it cannot enforce a requested route, I disclose the fallback and its limits.

Each writer receives a clean context and a brief naming its files, changes, and check. I compare the returned diff with the approved plan and decide whether it fits.

In the example, groups A and C start from the plan together. Group B waits until I accept A's result. Completion waits until all three reviews pass.

Check the result

I check each return against its allowed files, run its stated check when one applies, and read its diff against the plan. A failed group gets its own recovery; accepted work stays accepted.

If a writer changes a file outside its brief, I stop further delegation and ask the user to decide how to proceed. A passing check does not give a writer permission to expand the task.

For a final behavioral change, I run the planned verification. For prose or formatting, I inspect the diff; I commit only when asked.

Cost and time are part of why I work this way. Their actual totals depend on model choices, task size, retries, and review. I want to spend reasoning where a wrong decision could mean doing the work again.

The plan makes that division possible. I can give a writer a narrow task because the scope and the way to check it are already visible.