Prompt patterns

The best orchestration prompt describes the outcome and the boundaries that matter. super.engineering supplies the provider with the tool-use contract; the provider supplies the operational details.

Start with the smallest useful prompt

For many tasks, one sentence is enough:

Use the sc CLI to orchestrate this feature through implementation, verification, and review.

The shorter “Orchestrate this…” also invokes the app-managed workflow. Naming the sc CLI makes the intended control surface explicit. “Use agents,” “delegate this,” or “work in parallel” alone asks for native provider subagents instead.

Add details when they affect the result:

Use the sc CLI to orchestrate this feature through implementation and independent review. Preserve backward compatibility, run the repository checks, and ask before changing the schema.

You rarely need to name commands, role labels, team size, or report formats. The injected context teaches the provider how to discover capabilities and operate the current CLI.

A practical prompt shape

Build a request from the parts you need:

[Invoke orchestration] + [desired outcome] + [material constraints] + [definition of done]

For example:

Use the sc CLI to orchestrate the sign-in fix. Work autonomously in the current worktree, preserve the existing session format, and finish only after targeted verification and a fresh correctness review.

Each part answers a useful question:

Invocation: Should the provider use app-managed orchestration?
Outcome: What should exist when the work ends?
Constraints: Which choices require human control?
Definition of done: What evidence should the lead collect?

Omit any part whose answer is obvious from the task or repository instructions.

Choose an autonomy level

Broad autonomy:

Use the sc CLI to orchestrate this task end to end. Choose the workflow after inspecting the repository, and proceed through verification without checkpoints.

Approval before launch:

Use the sc CLI to orchestrate a read-only inspection of the task and propose a team and workflow. Wait for my approval before launching sessions or editing files.

Approval only for risky choices:

Use the sc CLI to orchestrate this task autonomously. Ask before schema changes, new dependencies, destructive actions, or changes outside the requested scope.

Approval boundaries work better when they name decisions, not every operational step.

Guide team shape without designing it

When you do not care how many roles run:

Use the sc CLI to orchestrate this with the smallest useful team. Parallelize only independent work.

When the order matters:

Use the sc CLI to orchestrate a strict design → implementation → review sequence. Show me the design before implementation starts.

When independent review matters:

Use the sc CLI to orchestrate implementation and verification, then use a fresh read-only session for independent review. Verify each finding before changing code.

These prompts express dependencies and independence. The provider can then choose parallel team fan-out or manually sequenced sessions.

Route providers and models

Naming a provider or model also invokes orchestration:

Use Claude to lead this change and Codex for bounded implementation work.

Route by workload when exact model IDs do not matter:

Use a strong reasoning model for planning, integration, and difficult review. Use a fast model for narrow, well-specified implementation or research tasks. Escalate ambiguity to the lead.

Set a substitution policy when availability matters:

Use Fable 5 as the lead and do not substitute another model without asking.

Or:

Prefer the providers I named, but choose an available substitute if needed and report the change.

The provider resolves names against live capabilities. You do not need to ask it to run a capability command unless you are diagnosing a failure.

Ask for visible sessions

Visible app behavior invokes orchestration even without the word “orchestrate”:

Run Claude and Codex side by side in visible app-managed sessions while they compare these approaches.

Describe the experience, not layout coordinates:

Keep the lead and active implementer visible side by side. Preserve the other sessions in tabs, and bring the reviewer forward when review starts.

The provider inspects the current layout and chooses the correct targets.

Shape communication

For routine peer collaboration:

Let the frontend and backend roles resolve questions about their shared interface directly. Escalate decisions that change scope or ownership to the lead.

For centralized control:

Route architecture and scope decisions through the lead. Peers may exchange factual information directly.

You do not need to prescribe message commands or labels. The lead creates stable addresses and uses the app-managed communication tools.

Define completion

A useful completion clause says what the lead must verify:

Finish after integrating the work, inspecting the final diff, running the relevant checks, and resolving verified review findings. Report failures and remaining uncertainty.

For review-only work:

Return one deduplicated list of evidence-backed findings. Do not edit files.

Agent reports are inputs to the lead’s judgment, not proof that the work is correct.

Avoid over-prompting

Include a detail when it changes the desired result, approval boundary, or user experience. Leave it out when it merely restates the provider’s injected contract.

Usually unnecessary:

exact sc commands;
instructions to load orchestration guides or inspect capabilities;
role reporting syntax;
labels chosen before the team exists;
a fixed number of agents without task-based ownership; and
parallelism for work with unresolved dependencies.

Useful when intentional:

an exact provider or model;
whether substitutions are allowed;
a required sequence or approval gate;
visible layout expectations;
read-only or destructive-action boundaries; and
specific verification or review requirements.

Follow up on an active workflow

After orchestration starts, use the role names the lead established:

Ask the UI role to preserve the current component API and continue in the same session.

Wait for the API role before starting integration.

Stop the research role, but leave its session visible.

Send the verified review findings back to the existing implementer.

Follow-ups need no new invocation phrase because they operate on the active workflow. A new standalone session does need one.

If orchestration does not start

If a provider discusses orchestration without invoking it, strengthen the request in stages:

“Use the sc CLI to orchestrate this with super.engineering.”
“Use app-managed sessions, not native subagents.”
“Run sc instructions orchestration, then begin the app-managed workflow.”

Reserve exact commands for scripts, diagnostics, and advanced control. See CLI automation and Automation recipes for that layer.

Ask the CLI for current help

The installed CLI is the source of truth for current syntax:

sc help
sc help team
sc help agent
sc instructions
sc instructions orchestration

Use sc help for the full command surface and sc help <command> for focused command help. Use sc instructions to discover the agent-facing guides and sc instructions orchestration for the orchestration workflow. You can run these commands yourself or ask the provider to consult them.