---
name: verify-design-a
type: action
description: Architecture review in hindsight — what to question, dependency analysis, abstraction assessment
user-invocable: false
---

> **Action skill** — Architecture review procedures: dependency analysis, abstraction assessment, output format.

# Design Review

Evaluating code architecture in hindsight — now that it's built, does the structure make sense?

## What to Question

**Type and class design** — Why does this class exist? Would functions suffice? Should these be separate types or one? Is inheritance justified?

**Module structure** — Why is this code in this package? Should modules be split or merged? Are boundaries in the right places? Does directory structure reflect architecture?

**Dependencies** — Why does A depend on B? Could it be inverted? Hidden coupling through shared state? Circular dependencies? Dependencies pointing toward stability?

**Abstractions** — Earning their complexity? More than one implementation? Interface premature? Would concrete code be clearer?

## Approach

Diagrams first. Show module dependencies, data flow, layer structure. Reference diagrams in every finding.

Format findings as:
- OBSERVATION: What the current design does
- QUESTION: Why is it this way?
- ALTERNATIVE: Different approach to consider
- IMPACT: What would change

Not naming/formatting (that's style). Not fake code (that's larp). Sound architecture is the goal, not findings.

## Output Format

```
## Concern: {title}

DIAGRAM: {ASCII dependency or data flow diagram}
OBSERVATION: What the current design does
QUESTION: Why is it this way? What's the tradeoff?
ALTERNATIVE: Different approach to consider
IMPACT: What would change if refactored
```

Refactor candidates as prioritized list with FROM/TO/TRADEOFF for each.