메뉴
Use when fanning out many write-capable sub-agents across one build — pre-wire the shared seams, own files disjointly, namespace shared state, and re-run every agent's gate yourself.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | parallel-agent-fan-out |
| description | Use when fanning out many write-capable sub-agents across one build — pre-wire the shared seams, own files disjointly, namespace shared state, and re-run every agent's gate yourself. |
When a large build decomposes into many genuinely independent units, one write-capable sub-agent per unit lands them in parallel wall-clock time. The throughput is real — and so is the new failure surface: agents collide on shared files, clobber each other's state on a shared backend, and report "done" over work that was never proven. The coordinator's job is to design the independence in up front and to trust none of the reports at the end.
Reach for this when you are the coordinator about to spawn more than a couple of write-capable agents against one repository or one shared live system — implementing N modules of a large surface, migrating N call-sites, covering N endpoints, porting N files — and the units are independent enough to build in parallel.
Red-flag thoughts — if you catch yourself thinking any of these, STOP and apply this skill:
<unit>-…) and forbid it from mutating or deleting any resource it did not create; clean up in a finalizer that runs even on failure. Parallel agents share one reality; without namespacing they overwrite each other's fixtures and delete each other's state. This is secrets-and-teardown-discipline's "own only your scope" made a hard rule.Fan-out multiplies throughput and multiplies the ways work can silently conflict or silently lie. Two agents mutate the same shared record and each passes its own test while corrupting the other's. One agent uninstalls a dependency another is mid-test on, or edits a module a third imports. An agent edits the file everyone registers into and the merge is a pile of conflicts. An agent reports "all green" over mocks that never touched the real system. None of these is caught by trusting the agents; every one is caught by designing the units to be independent (pre-wire, disjoint ownership, namespaced state, isolated runtimes) and then re-running each unit's gate against the merged whole. The coordinator's leverage is entirely front-loaded and back-loaded: make the middle boring by making the units actually independent, and make the end trustworthy by verifying mechanically instead of reading reports. Skip either half and the speed-up is paid back with interest in a corruption you find late and can't localize.
A second build the pack draws on — a REST API client library extended to cover an external system's entire API, roughly 340 endpoints across 15 namespaces, verified against one containerized live server — was built exactly this way. The coordinator first pre-wired the client registry and a stub module for every namespace, then handed each of 15 implementer agents a manifest of exactly its files (sync and async client modules, two unit-test files, one live-integration test, an example, and a docs page) plus a live-server brief, and forbade touching the registry or any other namespace's files. Every resource an agent created on the shared server was prefixed <tool>-<namespace>- and torn down in a finalizer, with a standing rule never to touch a resource it hadn't created — which is what kept the agents from clobbering each other's fixtures on the shared backend. The two real cross-agent incidents that happened anyway were not on the data backend at all but on the shared execution environment: one agent transiently uninstalled a shared package another was mid-test on, and another hit a transient import break from a third agent's in-flight edit to a module it imported. Neither was prevented by file ownership or resource namespacing; both were caught only because the coordinator re-ran every namespace's unit and live-integration suite itself instead of trusting the agents' "all green" reports. All 15 units merged with zero failures after that independent re-verification. The portable shape holds on any stack: pre-wire the seams, cut along real independence, namespace on shared substrate, isolate the runtime, serialize the join, and re-run every unit's gate yourself before you believe it.
What a machine can check: the seams and the joins. Ownership manifests as data, with a join-time check that each agent's diff touched only its manifest — violations revert mechanically; namespacing certified by a finalizer that queries the shared substrate for un-prefixed leftovers; every unit's own gate re-run by the coordinator against the merged tree, believing the exit code and not the prose; and the whole-scope adversarial review as a required final stage, because per-unit gates are structurally blind between units.
Related skills:
Use when wiring a project's dev workflow (local stack, test tiers, gates, docs), or when naming make targets in a repo that has siblings — build a thin self-documenting Makefile facade over real scripts, name targets from the shared cross-repo vocabulary, and split env files by owner so targets consume them but never write them.
Use when you need to prove a feature actually delivers its intended outcome to a user or caller, not just that its code paths run — write executable acceptance tests against real, observable outcomes, derived from the spec before or independent of the implementation.
Use when adding any new capability to a working system — ship it behind a flag or optional collaborator that defaults to prior behavior.
Use when a spec, plan, or implementation must be independently reviewed before it is trusted, committed, or advanced to the next phase — dispatch a fresh reviewer per named lens whose job is to refute the artifact, not confirm it.
Use when building automation that edits, tests, or deploys itself — an agent that regenerates its own code, a self-updating pipeline, any loop that modifies the thing running it.
Use when about to call any integration, deployment, or hard guarantee "done" — prove it live end-to-end and capture the run as evidence.