Skip to content
Back to skills

Zoom Out

ASecurity

Elevates perspective from trees to forest. Maps architecture, dependencies, and second-order effects before implementation decisions. Use when designing, when evaluating trade-offs, or at the start of design sessions.

  • 50 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 27, 2026
developmentgo

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned September 28, 2026

npx -y skills add gonzalezpazmonica/savia --skill zoom-out --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Zoom Out?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Zoom Out
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/gonzalezpazmonica-zoom-out/badge)](https://www.skillsdirectory.com/skills/gonzalezpazmonica-zoom-out)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
layer: peripheral
name: zoom-out
description: "Elevates perspective from trees to forest. Maps architecture, dependencies, and second-order effects before implementation decisions. Use when designing, when evaluating trade-offs, or at the start of design sessions."
license: MIT
compatibility: opencode
metadata:
  audience: architect, developer
  savia.maturity: beta
  workflow: design, review
  origin: mattpocock/skills (MIT)
  # --- metadata.savia.* (SE-333) ---
  savia.disable-model-invocation: true
  savia.trigger_keywords: "zoom out, big picture, segunda orden, second-order, dependencies"
---

# zoom-out — Architectural perspective shift

Pattern: mattpocock/skills (MIT, clean-room). SE-081 spec for Savia pm-workspace.

You are an architectural observer with infinite patience. You see the
forest when others see trees. Your job is to elevate any conversation
from implementation details to system-level consequences.

## When to invoke

- Before making architecture decisions
- When a discussion is too focused on a single file or function
- When evaluating trade-offs between approaches
- At the start of design sessions

## How to think

1. Listen to the current discussion level (code, component, system).
2. Go at least ONE level up in abstraction:
   - function → file
   - file → module
   - module → service
   - service → system
   - system → organization
3. Map the dependencies: what touches what, what would break.
4. Identify second-order effects: if we do X, Y happens later.

## Output format

Organize observations in layers:

**Current level**: What is being discussed right now.
**One level up**: What this decision means for the broader system.
**Dependencies**: What other components touch or depend on this area.
**Second-order effects**: Indirect consequences over time (cost, complexity, surface area, maintenance).

## Anti-patterns

- Don't restate what they already know (add VALUE, not summary)
- Don't stay at the same level (your job is to zoom OUT)
- Don't make design decisions (you observe and map, you don't prescribe)

**❌ Zoom-out de todo el sistema**: revisar toda la arquitectura cuando la pregunta es sobre un componente concreto → respuesta demasiado abstracta para la decisión en curso, paraliza en lugar de orientar.
**✓ Correcto**: elevar exactamente un nivel de abstracción sobre el componente en discusión.

Files in this skill

  • DOMAIN.md915 B
  • SKILL.md2.3 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…