Delegate and Parallelize

A single context working sequentially is the slowest possible configuration. The two resources this skill manages: wall-clock time (parallelism) and context budget (keeping file dumps and search noise out of the window where the real work happens). There's a third, subtler one: independence — a fresh context can be skeptical of your work in a way you cannot.

1. Parallel tool calls are free

Independent reads, greps, and commands belong in ONE message, not a sequence. Three files you know you need → three Read calls in the same block. This is pure latency saved at zero cost. Sequential calls are only required when one call's input depends on another's output.

2. Subagents for breadth, own hands for depth

Broad questions — "where is X handled", "how does auth flow work here", "find every call site of Y" — go to an Explore/search subagent that reads widely and returns conclusions. The dumps stay in its context; yours receives the answer. Reserve your own Read calls for files you are about to edit, where you need the exact text.

Rule of thumb: if answering requires opening more than ~3 files whose contents you won't need again afterward, delegate the sweep.

3. A subagent prompt is a contract

The subagent has none of your conversation context. Vague prompt → vague result → the run is wasted and you do the work anyway. Every delegation prompt needs:

• Context: paths, what the project is, what you already know
• The question, precisely scoped — one owner per question
• The deliverable format: "return a list of file:line with a one-sentence role for each; no code dumps" beats "look into X"
• Non-goals when relevant: "do not modify anything", "don't investigate the frontend"

4. Don't double the work

Once delegated, don't also run the search yourself while waiting. Once you've done something inline, don't delegate it "to be sure." One owner per question; wait for the result, then act on it.

5. Background the slow stuff

Test suites, builds, installs, servers: run them in the background and do useful work while they execute — review the diff, update the state file, prepare the next step. But read the output before relying on the result: a backgrounded command that failed silently while you built on top of it costs more than the sequential wait would have.

6. Buy independent skepticism

You cannot review your own work with fresh eyes — you'll re-walk the same reasoning groove that produced the bug. A fresh context can. For high-stakes findings or fixes, spawn a verifier agent whose explicit job is to refute the claim:

"Here is a claimed bug/fix: <claim + evidence>. Try to refute it. Check whether the code actually behaves this way, whether the fix handles <edge cases>, whether callers break. Default to skepticism; report CONFIRMED or REFUTED with evidence."

The prompt must ask for refutation, not review — "review this" produces agreement; "refute this" produces scrutiny. For critical work, several verifiers with different lenses (correctness, edge cases, does-it-reproduce) catch what one cannot.

7. Cost sanity

A subagent costs startup time and tokens, and returns a summary rather than ground truth. For one known file or one obvious grep, just do it yourself. Delegate when breadth (many files to sweep), parallelism (independent subtasks), or isolation (fresh skepticism; messy experiments you don't want polluting your context) pays for the overhead.