# Interface Forensics

> Reconstruct the design logic and grammar behind an existing interface from live UI, screenshots, source, or DOM. Use when analyzing why an interface works, rebuilding a reference, or extracting a system from an existing product.

- Skill: `dragoon0x/interface-forensics` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add dragoon0x/interface-forensics`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dragoon0x/interface-forensics/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: dragoon0x (https://skillmd.com/u/dragoon0x)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dragoon0x/interface-forensics

---


# Interface Forensics

## Mission

Understand why an existing interface feels the way it does.

Do not copy the surface. Reconstruct the decisions beneath it.

## Evidence

Use available live UI, screenshots, recordings, source, DOM, computed styles, assets, and interaction behavior. Label conclusions by evidence strength.

## Interface DNA

Reconstruct:

- hierarchy
- typography
- spacing
- shape
- color
- surface/material
- density
- component grammar
- interaction grammar
- motion grammar
- responsive logic
- state language

## Composition

Infer container hierarchy, alignment anchors, spacing groups, repeated modules, visual centers, and content boundaries.

## Typography

Determine how family, weight, size, line height, measure, wrapping, and hierarchy create the visual voice.

## Material

Determine whether depth comes from tonal difference, border, shadow, blur, overlap, or shape. Do not assume every layer represents elevation.

## Interaction

Identify trigger, response, state change, feedback, motion, interruption, and cancellation.

## Responsive logic

Determine invariants, adaptive rules, substitutions, collapsing behavior, and priority changes. Do not infer unseen behavior as fact.

## Implementation hypotheses

When source is unavailable, label likely mechanisms such as grid/flex, positioning, transforms, transitions, native controls, or state-driven rendering as hypotheses.

## Rebuild specification

When useful, produce:

**Interface DNA → Structure → Tokens → Components → States → Interaction → Motion → Responsive rules → Implementation hypotheses**

## Preserve intent

If rebuilding, identify which decisions define the interface's character. Do not blindly reproduce incidental artifacts.

## Anti-patterns

Avoid pixel tracing without hierarchy understanding, invented implementation claims, assuming one screenshot reveals responsiveness, and treating visual similarity as functional equivalence.

## Reference artifact

Use `references/interface-dna.md` to record reconstructed interface grammar with explicit confidence levels.

## Completion criteria

The underlying grammar can be explained well enough to reproduce the interface's intent without merely tracing its pixels.

## Expert Review Protocol

### First pass: understand

Before changing anything, identify the actual user outcome, the existing system, the relevant constraints, and the evidence available.

Do not begin by choosing a visual treatment.

### Second pass: compare

Ask:

- What is the simplest credible solution?
- What is the strongest alternative?
- What does the current solution cost?
- What behavior does each option teach the user?
- Which decision is easiest to reverse?
- Which failure would be most expensive?

Choose deliberately.

### Third pass: stress

Do not review only the happy path.

Apply pressure through:

- repetition
- interruption
- missing content
- long content
- slow operations
- narrow space
- large text
- keyboard use
- touch use
- focus changes
- error recovery
- restoration

Use only scenarios that are relevant to the surface.

### Fourth pass: inspect the implementation

When code exists, verify that the implementation preserves the interface decision.

Look for:

- duplicated sources of truth
- styling that bypasses the system
- state that can become stale
- behavior that differs from adjacent components
- abstractions that obscure rather than simplify
- dependencies that are not earning their cost
- performance work performed without evidence

### Fifth pass: critique the result

Ask:

> If this were shipped tomorrow, what would users notice that the builder has stopped noticing?

Look for:

- friction
- ambiguity
- inconsistency
- unnecessary movement
- weak recovery
- hidden state
- visual noise
- inaccessible behavior
- fragile edge cases

### Sixth pass: distinguish polish from substance

A useful change improves one or more of:

- understanding
- speed
- confidence
- recovery
- accessibility
- consistency
- maintainability

If a change improves none of these and only adds decoration, treat it as suspect.

### Seventh pass: verify

A claim is complete only when an appropriate form of evidence supports it.

Use:

- direct interaction
- tests
- runtime inspection
- visual comparison
- accessibility checks
- performance measurement
- source inspection

Do not claim a check that did not occur.

### Completion standard

Stop when:

1. the intended outcome is achieved
2. important states are handled
3. meaningful failure modes were considered
4. the interface fits its surrounding system
5. important claims are verified
6. remaining imperfections are lower-value than the risk of further change

The goal is not maximal polish.

The goal is a result that is difficult to improve without changing the underlying decision.