multi-agent-run

Multi-Agent Run — One Command to Orchestrate

This skill decomposes any complex task into parallel subtasks, executes them with multiple agents, and synthesizes a coherent answer.

One-line trigger:

[$oh-my-dynamic:multi-agent-run] 用 dynamic workflow 处理这个任务；App runtime 可用时使用内部 Codex subagents，否则走 in-chat fallback；大规模走 Codex CLI swarm。

Current v3.5.0 status:

• Preferred developer imports now use oh_my_dynamic.*; root-level files such as dynamic_workflow.py, codex_cli_swarm.py, and agent_broker.py are compatibility shims.

• Stable: Codex CLI swarm, adaptive dynamic workflow planner/replanner, broker reducer, examples/real_repo_review.py, static observability dashboards, round-aware compact evidence, and deterministic quality evals.

• Trust gates: sanitized evidence, python -m doctor --json, Bandit CI, MIT license, threat model docs, deterministic benchmark dry-runs, real v3.2 benchmark stability evidence, v3.5 official brief/demo/outreach docs, GitHub issue templates, and pytest coverage fail-under 80.

• Beta: worktree patch mode, checkpoint/resume, streaming progress events, and capability routing.

• Experimental: Codex App bridge, A2A gateway, and TEA protocol.

Codex App Default: Runtime-Gated Subagents

When triggered inside Codex App, this skill must work immediately after installation:

• If Codex subagent runtime/tools are available and the user asks for dynamic workflows, real subagents, parallel agents, or equivalent multi-agent execution, spawn real Codex internal subagents by default.
• Do not set a model override for spawned subagents. Let them inherit the current Codex App internal LLM/runtime.
• Do not require provider API keys or .env configuration for App-native subagent execution.
• Do not tell the user to use Codex CLI for ordinary App usage.
• Do not run the Python pipeline unless the user explicitly asks for the local Python engine, real provider calls, or dashboard files.
• If the user asks for dynamic workflow or adaptive workflow but not huge scale, use the planner/replanner flow conceptually in App mode; outside App-native subagents, the local dynamic_workflow.py runtime and scripts/record_adaptive_workflow_evidence.py are the matching CLI backends.
• Exception: if the user explicitly asks for dozens/hundreds of real Codex agents, maximum fan-out, CLI swarm, or equivalent large-scale execution, use the local codex_cli_swarm.py backend instead of the ordinary in-chat fallback. This backend launches many codex exec processes, feeds each worker prompt through stdin, streams stdout/stderr to per-agent files, keeps a run manifest/trace, and ingests JSON envelopes into AgentBroker.
• If the user asks for a release-quality adaptive evidence run, use python scripts/record_adaptive_workflow_evidence.py --goal "..." --required-coverage security,tests,docs --max-agents 50 --max-parallel 5 --dashboard; use --dry-run --output-dir /tmp/ohmy-adaptive only for shape checks.
• If the user asks to prove real replanner-generated agents, add --force-missing-coverage replanner-proof --max-rounds 2 so the deterministic trigger policy must ask the real replanner for follow-up agents.
• If the user asks for a real repo review demo or evidence run, use python examples/real_repo_review.py --agents 5 --max-parallel 3; use --dry-run --output-dir /tmp/ohmy-evidence only for CI/demo shape checks that must not launch Codex CLI.
• If the user asks to inspect progress/evidence after a run, use python scripts/render_workflow_observability.py --run-id RUN_ID --source .orchestry --output docs/evidence/RUN_ID-dashboard.html.
• If the user asks whether agent output quality is good enough, or asks for an eval, use python scripts/run_quality_eval.py --sample --output docs/evidence/sample_quality_eval.md for deterministic CI-safe shape checks, or pass a redacted responses JSON with --responses.
• If the user asks whether adaptive workflow is better than a baseline, use python scripts/run_benchmark.py --suite benchmarks/repo_review.json --mode single,fixed,adaptive --output docs/evidence/benchmark_v310_dry.json for a deterministic benchmark shape check, or add --real --fixtures security_command_surface,install_five_minute,tests_dynamic_workflow,evidence_redaction,docs_boundary_claims --output docs/evidence/benchmark_v310.json for release-quality Codex CLI evidence.
• If the user asks whether installation is healthy, use python -m doctor --json; before real Codex CLI workers, use python -m doctor --json --strict-real-codex.
• If the user asks for streaming progress or resume, use python -m dynamic_workflow "goal" --stream-events --checkpoint-dir .orchestry/checkpoints and resume with python -m dynamic_workflow --resume RUN_ID.
• Treat src/oh_my_dynamic/runtime/dynamic_workflow.py as the planner/replanner/reducer orchestration layer and src/oh_my_dynamic/codex/codex_cli_swarm.py plus codex_swarm_* helpers as the Codex CLI worker execution layer. Root-level modules are deprecated compatibility shims for one major version; see docs/V3_MIGRATION_GUIDE.md.
• If the user explicitly asks for concurrent code writing, use worktree mode: workspace_mode="worktree" and write_intent="patch". Do not auto-merge agent worktrees.
• If the user has not clearly granted write intent, stay read-only review by default.
• Use the Codex App bridge contract for real subagents: dispatch plan, per-subagent prompt, structured JSON envelope, and AgentBroker ingestion.
• Coordinate subagent collaboration through registered agents, explicit messages, artifacts, handoffs, review requests/responses, inboxes, and auditable synthesis. Prefer parent-orchestrated A2A-style exchange over hidden peer-to-peer communication.
• Use broker_gateway.py only when the user asks for a local HTTP/SSE transport surface or external tool integration; ordinary Codex App usage should stay inside the App-native subagent path.
• If native Codex subagent runtime/tools are unavailable, fall back to zero-config in-chat workflow execution using the current Codex App assistant/model.