Dive deeper

Dive Deeper

The user feels the current analysis is incomplete — blind spots, unexplored paths, or risks that haven't been considered. Your job is to find them.

How to work

Actually search the codebase — don't reason from memory. Use Grep to find call sites, Glob to find related files, Read to examine implementations. Every claim ("this function is called from 3 places") must be backed by a tool call. If you haven't grepped for it, you don't know it.

If something is unclear — the intent behind the change, which behavior is expected, or how a component is supposed to work — ask the user before guessing. A wrong assumption baked into the analysis is worse than no analysis. Keep questions focused and specific.

What to do

1. Map the blast radius

Start from the function/type/file at the center of the change. Trace outward:

• Who calls this? Grep for all call sites — not just the obvious ones. Check tests, UI bindings, interface implementations, closures, dependency injection.
• Who does this call? Follow the dependency chain down. If you're changing a service, what does it depend on? Could those break?
• Who shares data with this? Look for shared state — globals, singletons, injected objects, config keys, file paths, notification/event names.

Build a concrete list of affected files with line numbers. Not "this might affect some views" — name them.

2. Trace the full flow

Pick the most important user-facing scenario that touches this code. Walk through it step by step:

• What triggers it?
• What state must exist before it works?
• What state does it leave behind after?
• What happens if it's interrupted halfway (process killed, network lost, concurrent call)?

If the change touches multiple flows, trace each one. Don't say "this could be a problem" — show the specific sequence of events that leads to failure.

3. Surface edge cases

Think about the inputs and states the original plan didn't consider:

• Empty/nil/zero: Empty collection? Nil value? Zero count?
• Boundaries: First item, last item, single item, maximum allowed.
• Concurrency & reentrancy: Can two callers hit this simultaneously? Can it be called while already running?
• Migration: Does this change the shape of persisted data? What happens to existing data?
• Partial failure: If this fails halfway, is the state consistent or half-updated?

4. Present findings

For each finding, filter first: is this a real risk or theoretical noise? Does the current plan already handle it? Only report what actually matters.

Format:

### [Title]
Where: file:line
Risk: high / medium / low
Scenario: [concrete sequence of events leading to failure]
Fix: [specific change needed]

5. Revised plan

This is the main deliverable. Take the original plan and update it — add missing steps, reorder if needed, flag items that need extra attention. Make it clear what changed and why.

If the plan is actually solid after deep analysis, say so — "I checked X, Y, Z and the plan covers them." Don't manufacture problems to seem thorough.

What NOT to do

• Don't re-read files you already read — look at the ones you HAVEN'T.
• Don't list generic risks ("this could have race conditions") — show the specific race.
• Don't pad findings. Three real problems beat ten theoretical ones.
• Don't lose sight of the original task. Deep analysis serves the plan, not the other way around.