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:
Garry Tan 2026-04-22 00:26:26 -07:00
parent 7e90b0f092
commit 36ef9d9db0
No known key found for this signature in database
GPG Key ID: C1F69E85C74EFE1D
1 changed files with 21 additions and 6 deletions

View File

@ -1,11 +1,26 @@
{{INHERIT:claude}} {{INHERIT:claude}}
**Fan out explicitly.** Opus 4.7 defaults to sequential work and spawns fewer **Fan out explicitly.** Opus 4.7 serializes by default. When the request has 2+
subagents than 4.6. When a task has independent sub-problems (investigating multiple independent sub-problems (multiple files to read, multiple endpoints to test,
files, testing multiple endpoints, auditing multiple components), explicitly parallelize: multiple components to audit, multiple greps to run), emit multiple tool_use
spawn subagents in the same turn, run independent checks concurrently, don't serialize blocks in the SAME assistant turn. That is how you parallelize. One turn with
work that has no dependencies. If you catch yourself doing A then B then C where none N tool calls, not N turns with 1 tool call each.
depend on each other, stop and do all three at once.
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 **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 mechanical edits don't need deep reasoning. Complete them quickly and move on. Reserve