zoom-out

name	zoom-out
description	Gain system-level context before making changes. Use when working in unfamiliar code, before changes that touch multiple modules, when debugging cross-cutting concerns, or when the agent seems to be making narrow assumptions.
argument-hint	[module or file you're currently in]

Zoom Out — System-Level Context

"You can't understand a city by staring at one brick."

Philosophy

When deep in implementation details, the agent risks making changes that are locally correct but globally wrong. This skill forces a step back to understand the broader system context before proceeding.

Workflow

Step 1: Identify Your Position

• What module/file are you in? Name it explicitly.
• What is this module's responsibility? Check CONTEXT.md first, then docs, then infer.
• Who calls this module? Trace callers upward to user-facing features.
• What does this module depend on? Trace dependencies downward.

Step 2: Map the Neighborhood

[Caller A] ──→ [Current Module] ──→ [Dependency X]
[Caller B] ──→       ↕              ──→ [Dependency Y]
                    [Peer Module]

For each connected module: what it does (one sentence), how it interacts with current module, whether a change here would affect it.

Step 3: Trace the Data Flow

What data enters this module? What transformations happen? What data leaves? This reveals the module's true purpose beyond its stated responsibility.

Step 4: Check Domain Terms

Reference CONTEXT.md. Are the terms you're using consistent with the project's shared language? If terms are missing, note them for update.

Step 5: Assess Impact

• Blast radius: Which modules/features would be affected by a change here?
• Tests to update: Which test files cover this module?
• Risks: What could go wrong?
• Recommendation: Proceed / Modify approach / Reconsider

Output

## Zoom-Out: [Current Module]

### Position
- **Module:** [name]
- **Responsibility:** [one sentence]
- **Called by:** [callers]
- **Depends on:** [dependencies]

### Data Flow
[Key data in → transformations → data out]

### Impact Assessment
- **Blast radius:** [affected modules]
- **Tests to update:** [list]
- **Risks:** [what could go wrong]
- **Recommendation:** [proceed / modify / reconsider]

Anti-Patterns

• Going too broad — Focus on the neighborhood, not the entire system
• Skipping this step — When under time pressure, this is most valuable
• Treating the map as territory — Verify understanding by reading actual code

Integration

• Use before /architect to understand full impact
• Use before /diagnose when bug spans multiple modules
• Use during /grill for broader context
• Update CONTEXT.md with any new domain terms