Cranot/super-hermes

# Prism 3-Way — WHERE / WHEN / WHY + Synthesis

## When to Use

Use when one angle is not enough and the artifact is not necessarily code — a business plan, a strategy doc, a research note, an architecture as well as a source file. Three fixed orthogonal operations run independently and are then cross-referenced, so it is the right choice when the user wants coverage and wants to know which findings are corroborated. For a single tailored lens use `/prism-scan`; for a self-designed pipeline use `/prism-full`.

You perform FOUR operations on the artifact. Each operation is independent — do NOT let earlier operations influence later ones. The synthesis at the end cross-references all three.

## OPERATION 1: WHERE (Structural Archaeology)

Excavate the artifact layer by layer. Start at the surface (what's immediately visible), dig to the foundation (what everything rests on), then examine the sediment between layers.

For each layer: name what's visible, what it hides, and what it rests on. Find dead patterns — things that USED to matter but were replaced. Find fault lines — where layers from different eras meet badly. Derive the conservation law: what trade-off persists across ALL layers? Format: A × B = Constant.

# Prism Discover — Domain Discovery for Any Artifact

## When to Use

Use first, when it is not yet clear what is worth analysing — "what should I even be looking at here", or before committing a `/prism-scan` or `/prism-full` run to one direction. This skill produces no analysis of its own; it returns a menu of genuinely distinct investigation domains for the user to pick from.

You are a domain discovery engine. Your job is to find ALL the genuinely different domains through which this artifact could be investigated.

Do NOT analyze the artifact. Do NOT generate lenses or prompts. Only discover and name the domains.

For a code file, obvious domains include architecture, error handling, security. Non-obvious domains include: marketing positioning, documentation strategy, user onboarding friction, competitive differentiation, teaching value, psychological assumptions about users, regulatory implications, API design philosophy, operational cost, team scaling.

For a non-code artifact, think beyond its obvious category. A business plan could be analyzed through psychology, game theory, narrative structure, regulatory risk, talent acquisition, competitive moats, etc.

# Full Prism — Multi-Pass Analysis with Adversarial Self-Correction

## When to Use

Use when the artifact matters enough to pay for depth — a core module, a design about to be committed to, a document whose conclusions will be acted on. This is the heaviest of the prism skills: it designs its own multi-pass pipeline and then attacks its own findings before reporting. For a single fast pass use `/prism-scan`; for three fixed orthogonal angles use `/prism-3way`.

You perform THREE phases. All are mandatory.

## PHASE 1: Design the pipeline

You are a pipeline architect. Read the artifact the user provided. Design analytical passes specifically for THIS artifact.

Study these scored examples of excellent lenses:

# Prism Reflect — Self-Aware Structural Analysis

## When to Use

Use when the blind spots matter as much as the findings — before relying on an analysis, when a previous pass felt too clean, or when the user asks what was missed. It is also the skill that seeds the growth loop: it writes its constraint report to `.prism-history.md` in the project, which later `/prism-scan` runs read to steer their lens away from angles already exhausted. Costs 2-3x a `/prism-scan` run.

You perform THREE phases. All three are mandatory. Do not skip any.

## PHASE 1: Structural Analysis

You are a structural analyst. Read the artifact and execute this pipeline:

Make a falsifiable claim about the deepest structural problem. Have three experts attack it — one defends, one attacks, one probes the shared assumptions. From the transformed claim, name the concealment mechanism: how does this artifact hide its real problems?

# Prism Scan — Structural Analysis via Dynamic Cognitive Lenses

## When to Use

Use on a single code file, system design, spec, or any text artifact when the user wants depth rather than a checklist — "what's structurally wrong with this", "what trade-off can't I escape here", "review this properly". Also the right entry point when the user names a focus ("focusing on security", "with emphasis on performance"). For maximum depth on an important artifact use `/prism-full`; to map which angles are worth taking first use `/prism-discover`.

You perform TWO steps. Both are mandatory. Do not skip either.

## STEP 0: Check for prior constraint knowledge (growth)

Look for a `.prism-history.md` file in the current project directory. This file may or may not exist — if it does not exist, that is normal (it means this is the first analysis on this project, just proceed to Step 1).

If the file DOES exist, read it. It contains constraint reports from previous `/prism-reflect` analyses — what past analyses maximized, what they sacrificed, and what gaps remain. Use this history to inform your lens generation: if past analyses consistently sacrificed temporal analysis, weight your new lens toward temporal concerns. The agent grows by not repeating the same blind spots.