/ApertureOscillation

name: ApertureOscillation
version: 1.0.9
description: "3-pass scope oscillation that holds a question constant while shifting zoom — narrow/tactical, wide/strategic, then synthesis — to surface design tensions, scope recommendations, and coherence assessments invisible at any single zoom level. USE WHEN aperture oscillation, oscillate scope, zoom in and out, tactical vs strategic, scope framing, design tension, system coherence check, local vs global design, wrong scope, scope negotiation. NOT FOR lens rotation across angles (use IterativeDepth)."

Customization

**Before executing, check for user customizations at:** `~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/ApertureOscillation/`

If this directory exists, load and apply any PREFERENCES.md, configurations, or resources found there. These override default behavior. If the directory does not exist, proceed with skill defaults.

ApertureOscillation

What It Does

Runs a question through 3 passes at different zoom levels — narrow/tactical, wide/strategic, then synthesis — while holding the question itself constant. The first pass captures what a component wants to be on its own. The second captures what the system needs it to be. The third finds where those two views disagree, and that gap is the output: design tensions, scope recommendations, coherence checks.

The Problem

A component designed in isolation gets its own clean logic. The same component designed inside a stated system vision inherits different constraints. Pick one zoom level and you miss the other — you ship something that works perfectly on its own but fights the system, or something that serves the system but ignores the component's natural shape. The most expensive rework comes from exactly this mismatch, discovered mid-build. Holding the question constant while varying the scope surfaces the mismatch before you commit.

How It Works

Grounded in the observation that LLMs (and humans) produce different outputs depending on the scope of the framing context. A component designed in isolation has its own logic. The same component designed within a stated system vision inherits different constraints. The delta between these two framings is where the insight lives.

Instead of rotating analytical lenses (IterativeDepth) or generating divergent ideas (BeCreative), ApertureOscillation holds the question constant but shifts the **scope envelope** around it across 3 structured passes:

1. **Narrow Aperture (Tactical-first):** The specific thing is primary. Big-picture context is background. This captures what the component naturally wants to be — its own internal logic and shape.

2. **Wide Aperture (Strategic-first):** The vision/system goal is primary. The specific thing is derived from it. This captures what the system needs the component to be — coherence, alignment, constraints you'd miss thinking locally.

3. **Oscillation (Synthesis):** Feed both outputs. Ask where the tactical and strategic views diverge. The tensions, gaps, and surprises between the two framings are the output — the things neither pass alone would surface.

How It Differs from IterativeDepth

| Dimension | IterativeDepth | ApertureOscillation | |-----------|---------------|---------------------| | **What varies** | Analytical lens (failure, stakeholder, temporal...) | Scope/zoom level (narrow, wide, synthesized) | | **Pass count** | 2-8 | 3 (fixed) | | **Input** | Single problem statement | Two inputs: tactical target + strategic context | | **Output** | Richer requirements from multiple angles | Design tensions between local and system-level views | | **Best for** | Requirement discovery, blind spot elimination | Architecture decisions, feature design, system coherence | | **When to combine** | Use IterativeDepth first (understand the problem), then ApertureOscillation (understand where the solution fits) |

Use / Win

**When to use:** Any time you're building something specific within a larger system and need to ensure the local design serves the global vision — without losing the component's own logic.

Concrete triggers:

• **Architecture decisions** — "Should this be a service, a library, or inline?" depends entirely on whether you're zoomed into the component or zoomed out to the system.
• **Feature design** — The feature a user asks for vs. the feature the product needs are often subtly different. Oscillation surfaces the gap.
• **System coherence checks** — When adding to existing infrastructure, the new piece must serve both its own purpose and the system's. Single-scope framing misses one or the other.
• **Design reviews** — Before committing to an approach, oscillate scope to check that the tactical plan and the strategic vision agree.
• **Scope negotiation** — When the user says "build X" and X could be simple or complex depending on context, oscillation reveals which scope is appropriate.

**What you win:**

• **Design tensions surfaced before they become mid-build surprises.** The most expensive rework comes from a component that works perfectly on its own but doesn't serve the system.
• **Scope clarity.** Seeing the same question at narrow and wide aperture often reveals that the obvious scope is wrong.
• **Coherence confidence.** When tactical and strategic views align, you can build with conviction. When they diverge, you know exactly where to make tradeoffs.

Workflow Routing

| Workflow | Trigger | File | |----------|---------|------| | Oscillate | "aperture oscillation", "oscillate scope", "zoom in/out", "tactical vs strategic" | `Workflows/Oscillate.md` | | Oscillate | An Algorithm run selects the ApertureOscillation capability while scoping | `Workflows/Oscillate.md` |

Quick Reference

• **3 passes** — always 3 (narrow, wide, synthesis)
• **2 inputs** — tactical target (what you're building) + strategic context (why, the bigger picture)
• **Output** — design tensions, scope recommendations, coherence assessment
• **Integration point** — OBSERVE (