agent-fanout

Name: agent-fanout
Author: neuromechanist

37stars7forks

How to install agent-fanout?

neuromechanist/research-skills/agent-fanout

$npx -y skills add neuromechanist/research-skills --skill agent-fanout

Installs into the current project.

Summary

Use this skill when the user asks to \"fan out agents\", \"spawn agents\", \"use an agent team\", \"parallel agents\", \"delegate to subagents\", \"act as team lead\", \"orchestrate implementation\", \"fan out teammates\", or when a task decomposes into 2+ independent work items

Files · 1

View on GitHub

SKILL.md

1	# Agent Fan-Out and Teams
2
3	Orchestrate multiple subagents or teammates to explore, implement, review, and
4	validate in parallel. This skill makes every judgment call explicit: when to fan
5	out, how many agents, which model, what to put in each prompt, how to supervise,
6	and how to combine results.
7
8	## When to fan out (decision table)
9
10	\| Situation \| Action \|
11	\| --- \| --- \|
12	\| Single bounded question ("where is X defined?") \| No fan-out. Search directly or use one read-only explorer. \|
13	\| Open-ended audit/review of a system with 2+ independent subsystems \| One read-only explorer per subsystem, in parallel. \|
14	\| Multiple root-caused issues, each fixable independently \| One implementer per issue, each in its own git worktree. \|
15	\| One pull request (PR) ready for review \| One review panel (2-5 reviewers, see Review panels below). \|
16	\| Sequential work where step N needs step N-1's output \| Do NOT parallelize. Run one agent at a time or do it inline. \|
17	\| Task needs secrets, deploy rights, or user-only credentials \| Do NOT delegate. Keep it in the main session (mark the task "owner: lead"). \|
18
19	Do not fan out for work you can finish inline in a few minutes; a subagent costs
20	setup, supervision, and synthesis time.
21
22	## Hard limits (compute BEFORE launching)
23
24	1. Before any fan-out, compute the worst case: `finders x max findings per
25	finder x verifiers per finding + implementers + reviewers`. Write the number
26	down in your plan.
27	2. Budget: 10-20 agents per run for routine work; hard cap 40. If the
28	math exceeds the routine budget, say so and justify it; if it exceeds 40,
29	cut scope before launching: fewer lenses, findings capped per agent
30	(`maxItems`-style limits in the prompt), one verification vote instead of
31	three. Going past 40 requires explicit user approval in the same
32	conversation. If the user's own configuration states a stricter cap, the
33	stricter number wins.
34	3. Prefer waves of 10 or fewer concurrent agents. Finish and synthesize a wave
35	before launching the next.
36	4. Every phase plan states its own agent budget and routing up front (for
37	example "Sol lead + Terra phase planner + Luna implementer/reviewer,
38	~4 agents total").
39	5. If you hit a rate limit: stop spawning, schedule one backoff wait, resume
40	staggered. Narrate as a status update, not a question.
41
42	Evidence for the cap: an uncapped review-verify fan-out in a real session
43	reached ~130 agents, rate-limited the account, and disrupted the live product
44	under review. Compute the count first.
45
46	## Roles and model routing
47
48	Keep the lead/orchestrator on the strongest available reasoning tier. The lead
49	owns requirements, architecture, irreversible decisions, supervision,
50	load-bearing verification, and final synthesis. Delegate bounded plan
51	elaboration to the intermediate tier only after the architecture is fixed.
52	Delegate implementation to the worker tier only after the brief names exact
53	files, decisions, tests, and gates.
54
55	Worker agents perform near lead quality only when three controls are present:
56	a full lifecycle brief with exact values and named tests, mechanical gates
57	(lint, typecheck, tests, and zero new diagnostics), and lead verification of
58	the result. If any control is missing, keep the work on the lead or
59	intermediate tier.
60
61	### Ecosystem routing
62
63	Use an exact alias only when the current runtime exposes it. Otherwise apply
64	the capability class in the final column.
65
66	\| Ecosystem \| Lead / architect / observer / synthesizer \| Phase-plan elaborator \| Implementer / focused reviewer / validator \| Capability fallback \|
67	\| --- \| --- \| --- \| --- \| --- \|
68	\| Claude Code \| Fable when available, otherwise Opus or `best` \| Opus for unresolved design; Sonnet after architecture approval \| Sonnet \| strongest / balanced / worker \|
69	\| OpenAI Codex \| Sol (`gpt-5.6-sol`) \| Terra (`gpt-5.6-terra`) \| Luna (`gpt-5.6-luna`) \| strongest / intermediate / clear-repeatable worker \|
70	\| GitHub Copilot CLI \| strongest available model \| balanced reasoning model \| cost-efficient coding model \| strongest / intermediate / worker \|
71	\| Other systems \| strongest available model \| intermediate model \| fastest model that passes the gates \| strongest / intermediate / worker \|
72
73	Codex Luna is appropriate only for clear, repeatable implementation from a
74	detailed plan. Escalate a worker to Terra or Sol when the task exposes an
75	unresolved architecture choice, repeatedly fails a gate for a non-mechanical
76	reason, or touches data integrity, encryption,

People who liked this also viewed

6 picks

Type

agent-fanout

37stars7forks

View on GitHub

How to install agent-fanout?

neuromechanist/research-skills/agent-fanout

$npx -y skills add neuromechanist/research-skills --skill agent-fanout

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Agent Fan-Out and Teams
2
3	Orchestrate multiple subagents or teammates to explore, implement, review, and
4	validate in parallel. This skill makes every judgment call explicit: when to fan
5	out, how many agents, which model, what to put in each prompt, how to supervise,
6	and how to combine results.
7
8	## When to fan out (decision table)
9
10	\| Situation \| Action \|
11	\| --- \| --- \|
12	\| Single bounded question ("where is X defined?") \| No fan-out. Search directly or use one read-only explorer. \|
13	\| Open-ended audit/review of a system with 2+ independent subsystems \| One read-only explorer per subsystem, in parallel. \|
14	\| Multiple root-caused issues, each fixable independently \| One implementer per issue, each in its own git worktree. \|
15	\| One pull request (PR) ready for review \| One review panel (2-5 reviewers, see Review panels below). \|
16	\| Sequential work where step N needs step N-1's output \| Do NOT parallelize. Run one agent at a time or do it inline. \|
17	\| Task needs secrets, deploy rights, or user-only credentials \| Do NOT delegate. Keep it in the main session (mark the task "owner: lead"). \|
18
19	Do not fan out for work you can finish inline in a few minutes; a subagent costs
20	setup, supervision, and synthesis time.
21
22	## Hard limits (compute BEFORE launching)
23
24	1. Before any fan-out, compute the worst case: `finders x max findings per
25	finder x verifiers per finding + implementers + reviewers`. Write the number
26	down in your plan.
27	2. Budget: 10-20 agents per run for routine work; hard cap 40. If the
28	math exceeds the routine budget, say so and justify it; if it exceeds 40,
29	cut scope before launching: fewer lenses, findings capped per agent
30	(`maxItems`-style limits in the prompt), one verification vote instead of
31	three. Going past 40 requires explicit user approval in the same
32	conversation. If the user's own configuration states a stricter cap, the
33	stricter number wins.
34	3. Prefer waves of 10 or fewer concurrent agents. Finish and synthesize a wave
35	before launching the next.
36	4. Every phase plan states its own agent budget and routing up front (for
37	example "Sol lead + Terra phase planner + Luna implementer/reviewer,
38	~4 agents total").
39	5. If you hit a rate limit: stop spawning, schedule one backoff wait, resume
40	staggered. Narrate as a status update, not a question.
41
42	Evidence for the cap: an uncapped review-verify fan-out in a real session
43	reached ~130 agents, rate-limited the account, and disrupted the live product
44	under review. Compute the count first.
45
46	## Roles and model routing
47
48	Keep the lead/orchestrator on the strongest available reasoning tier. The lead
49	owns requirements, architecture, irreversible decisions, supervision,
50	load-bearing verification, and final synthesis. Delegate bounded plan
51	elaboration to the intermediate tier only after the architecture is fixed.
52	Delegate implementation to the worker tier only after the brief names exact
53	files, decisions, tests, and gates.
54
55	Worker agents perform near lead quality only when three controls are present:
56	a full lifecycle brief with exact values and named tests, mechanical gates
57	(lint, typecheck, tests, and zero new diagnostics), and lead verification of
58	the result. If any control is missing, keep the work on the lead or
59	intermediate tier.
60
61	### Ecosystem routing
62
63	Use an exact alias only when the current runtime exposes it. Otherwise apply
64	the capability class in the final column.
65
66	\| Ecosystem \| Lead / architect / observer / synthesizer \| Phase-plan elaborator \| Implementer / focused reviewer / validator \| Capability fallback \|
67	\| --- \| --- \| --- \| --- \| --- \|
68	\| Claude Code \| Fable when available, otherwise Opus or `best` \| Opus for unresolved design; Sonnet after architecture approval \| Sonnet \| strongest / balanced / worker \|
69	\| OpenAI Codex \| Sol (`gpt-5.6-sol`) \| Terra (`gpt-5.6-terra`) \| Luna (`gpt-5.6-luna`) \| strongest / intermediate / clear-repeatable worker \|
70	\| GitHub Copilot CLI \| strongest available model \| balanced reasoning model \| cost-efficient coding model \| strongest / intermediate / worker \|
71	\| Other systems \| strongest available model \| intermediate model \| fastest model that passes the gates \| strongest / intermediate / worker \|
72
73	Codex Luna is appropriate only for clear, repeatable implementation from a
74	detailed plan. Escalate a worker to Terra or Sol when the task exposes an
75	unresolved architecture choice, repeatedly fails a gate for a non-mechanical
76	reason, or touches data integrity, encryption,

People who liked this also viewed

6 picks

Type