mirror of
https://github.com/garrytan/gstack.git
synced 2026-05-02 03:35:09 +02:00
refactor(opus-4.7): rewrite fanout nudge to show parallel tool_use pattern
The original fanout nudge told 4.7 to "spawn subagents in the same turn"
and "run independent checks concurrently" in prose. An E2E eval on
claude-opus-4-7 reading 3 independent files showed zero effect: both
overlay-ON and overlay-OFF arms emitted serial Reads across 3-4 turns.
Rewrite follows the same "show not tell" principle the PR introduced for
voice examples. The nudge now includes a concrete wrong/right contrast
showing the exact tool_use structure:
Wrong (3 turns):
Turn 1: Read(foo.ts), then wait
Turn 2: Read(bar.ts), then wait
Turn 3: Read(baz.ts)
Right (1 turn, 3 parallel tool_use blocks in one assistant message):
Turn 1: [Read(foo.ts), Read(bar.ts), Read(baz.ts)]
Applies to Read, Bash, Grep, Glob, WebFetch, Agent, and any tool where
sub-calls don't depend on each other's output.
Effect on test/skill-e2e-opus-47.test.ts fanout eval: unchanged (both
arms still 0 parallel in first turn via `claude -p`). May land better in
Claude Code's interactive harness, where the system prompt + tool
handlers differ. Tracked as P0 TODO for follow-up verification in the
correct harness.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -1,11 +1,26 @@
|
||||
{{INHERIT:claude}}
|
||||
|
||||
**Fan out explicitly.** Opus 4.7 defaults to sequential work and spawns fewer
|
||||
subagents than 4.6. When a task has independent sub-problems (investigating multiple
|
||||
files, testing multiple endpoints, auditing multiple components), explicitly parallelize:
|
||||
spawn subagents in the same turn, run independent checks concurrently, don't serialize
|
||||
work that has no dependencies. If you catch yourself doing A then B then C where none
|
||||
depend on each other, stop and do all three at once.
|
||||
**Fan out explicitly.** Opus 4.7 serializes by default. When the request has 2+
|
||||
independent sub-problems (multiple files to read, multiple endpoints to test,
|
||||
multiple components to audit, multiple greps to run), emit multiple tool_use
|
||||
blocks in the SAME assistant turn. That is how you parallelize. One turn with
|
||||
N tool calls, not N turns with 1 tool call each.
|
||||
|
||||
Concrete example. If the user says "read foo.ts, bar.ts, and baz.ts":
|
||||
|
||||
Wrong (3 turns):
|
||||
Turn 1: Read(foo.ts), then you wait for output
|
||||
Turn 2: Read(bar.ts), then you wait for output
|
||||
Turn 3: Read(baz.ts)
|
||||
|
||||
Right (1 turn, 3 parallel tool calls):
|
||||
Turn 1: [Read(foo.ts), Read(bar.ts), Read(baz.ts)] ← three tool_use blocks,
|
||||
same assistant message
|
||||
|
||||
This applies to Read, Bash, Grep, Glob, WebFetch, Agent/subagent, and any tool
|
||||
where the sub-calls do not depend on each other's output. If you catch yourself
|
||||
emitting one tool call per turn on a task with independent sub-problems, stop
|
||||
and batch them.
|
||||
|
||||
**Effort-match the step.** Simple file reads, config checks, command lookups, and
|
||||
mechanical edits don't need deep reasoning. Complete them quickly and move on. Reserve
|
||||
|
||||
Reference in New Issue
Block a user