Menu
Run automation shape routing.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Temporary inboxes for agent signup QA — create disposable addresses, wait for verification email, extract OTP or magic links. Use when automating signup, login, or email verification without parsing HTML manually.
Spin up isolated sandboxes ("boxes") for coding agents, run them in parallel, queue background runs with -i, and push commits safely through the host relay. Use when the user wants to run Claude Code / Codex / OpenCode in a sandbox, start more boxes, attach to a running box, or otherwise operate the `agentbox` CLI on their laptop.
Use when building an HTTP val — a web endpoint, API route, webhook receiver, or any val that responds to HTTP requests. Covers the handler signature, Hono usage, the endpoint URL, CORS behavior, redirects, and Val Town-specific limitations.
Use when creating a new val and choosing which starter to fork. Covers the catalog of official starter templates, which project shape each one fits, and when forking an existing val is the better starting point.
Switch coding-agent accounts on a usage/rate limit, routed by host and agent.
Use Agent Mail from Codex for file leases, notifications, inboxes, and conflict prevention.
| name | automation-shape-routing |
| description | Run automation shape routing. |
The trap this kills: "I built a lot of skills; they should become orchestration scripts." Mostly false. Most orchestration-looking skills are either long-lived/human-attachable (stay ATM) or hard-sequential (stay skills). The win is the routing rule, not a migration project.
| Shape | What it is | Mechanism |
|---|---|---|
| Orchestration | Deterministic, reproducible fan-out / pipeline / loop over sub-agents, each returning structured output | Codex orchestration — codex exec driving spawn_agents (parallel fan-out), staged pipelines, and loop-until-budget, with an output_schema per sub-agent. Headless, reproducible, bounded concurrency. |
| ATM swarm | Long-lived, human-in-the-loop multi-agent run | atm (the CLI) driven by $using-atm — persistent tmux panes running whole $rpi/$evolve loops over a bead queue, with attach + nudge + kill/relaunch and mail/locks coordination. |
| Plain skill | One model reasoning through a procedure or knowledge | A single SKILL.md. No fan-out, or a strictly sequential edit-loop. |
Ask in order:
One-line litmus:
deterministic DAG + structured JSON + no human-attach + headless-wanted → Orchestration long-lived + attachable + open-ended file edits / fluid population → ATM no fan-out, or hard-sequential edit loop → plain skill
A live three-legged spike (~/dev/agentops-3cat-spike/) measured the same task on
all three backends. Two findings refine the rule:
codex exec + spawn_agents) when you don't.Degradation (ATM → native → beads floor) is governed by the
OrchestrationPort selector; opt out entirely with AGENTOPS_ORCHESTRATION=off →
beads floor, which always works.
→ Orchestration (deterministic fan-out / synthesize, structured returns):
council (N judges → consensus — near-trivial port), the planning half of
rpi, judge/refutation panels, any "fan out N analyses → triangulate" task.
→ Stay ATM (long-lived, attachable, open-ended edits, fluid population):
the *-with-atm family (hypothesis research, cross-model review swarms, browser
testing), plus swarm/crank in full epic-execution mode — they touch the
working tree and need wave-validity gating + human review.
→ Stay plain skill (no exploitable parallelism, or knowledge/one-shot): deliberately one-at-a-time loops (progressive reapply, multi-pass bug hunting); all reference docs; all single-shot transforms (jargon scrub, README authoring).
The operating loop is the worked example — a deterministic orchestration that
drives codex exec over spawn_agents with a per-sub-agent output_schema
(structured JSON, not free-form edits), parallel fan-out barriers (framing-lenses
/ judges / refutation / slices), explicit phase markers, budget-scaled fan-out
width, and bounded re-plan/retry. Start from this shape when authoring an
orchestration. It is also the proof that the AgentOps operating loop has two
conformant runtimes (skill-driven via rpi/crank/swarm/council, and
orchestration-driven via codex exec + spawn_agents) — the basis of the
agentops-core-sdk portability thesis. Hand off to $workflow-builder for the
authoring path.
This skill is the front door. It does not build; it routes. Once the shape is decided, hand off:
| Verdict | Next | What it does |
|---|---|---|
| plain skill | $skill-builder | Scaffold a new SKILL.md against the unified template → then $skill-auditor → $heal-skill. |
| Orchestration | $workflow-builder | Author a deterministic codex exec + spawn_agents orchestration with per-sub-agent output_schema. |
| ATM swarm | atm + $using-atm | Stand up + tend an ATM swarm running AgentOps loops ($rpi/$evolve) over a bead queue. |
State the verdict and the deciding axis in one line, then invoke the chosen builder. Do not scaffold here.
An orchestration is a composite capability (a composition of sub-capabilities
with typed control flow); a skill is a leaf. The portable contract for this —
a shape: skill|workflow discriminator, a StepGraph, a control_flow enum, a
budget, and an OrchestrationPort interface — is net-new SDK work. Port the
shape, not the engine: keep concrete orchestrators (Codex sub-agents, swarm
dispatch, scheduler — BC4/BC5) behind adapters.