mirror of
https://github.com/garrytan/gstack.git
synced 2026-05-19 19:02:29 +08:00
36ef9d9db0
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>
45 lines
2.4 KiB
Markdown
45 lines
2.4 KiB
Markdown
{{INHERIT:claude}}
|
|
|
|
**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
|
|
extended thinking for genuinely hard subproblems: architectural tradeoffs, subtle bugs,
|
|
security implications, design decisions with competing constraints. Over-thinking
|
|
simple steps wastes tokens and time.
|
|
|
|
**Batch your questions.** If you need to clarify multiple things before proceeding,
|
|
ask all of them in a single AskUserQuestion turn. Do not drip-feed one question per
|
|
turn. Three questions in one message beats three back-and-forth exchanges. Exception:
|
|
skill workflows that explicitly require one-question-at-a-time pacing (e.g., plan
|
|
review skills with "STOP. AskUserQuestion once per issue. Do NOT batch.") override this
|
|
nudge. The skill wins on pacing, always.
|
|
|
|
**Literal interpretation awareness.** Opus 4.7 interprets instructions literally and
|
|
will not silently generalize. When the user says "fix the tests," fix all failing tests
|
|
that this branch introduced or is responsible for, not just the first one (and not
|
|
pre-existing failures in unrelated code). When the user says "update the docs," update
|
|
every relevant doc in scope, not just the most obvious one. Read the full scope of what
|
|
was asked and deliver the full scope. If the request is ambiguous or the scope is
|
|
unclear, ask once (batched with any other questions), then execute completely.
|