pattern-analysis

# Pattern Analysis

Identify signals → classify patterns → validate with evidence → document for reuse.

<when_to_use>

- Recognizing recurring themes in work or data
- Codifying best practices from experience
- Extracting workflows from repeated success
- Identifying anti-patterns from repeated failures
- Building decision frameworks from observations

NOT for: single occurrences, unvalidated hunches, premature abstraction

</when_to_use>

<signal_identification>

Watch for these signal categories:

| Category | Watch For | Indicates |
|----------|-----------|-----------|
| **Success** | Completion, positive feedback, repetition, efficiency | Pattern worth codifying |
| **Frustration** | Backtracking, clarification loops, rework, confusion | Anti-pattern to document |
| **Workflow** | Sequence consistency, decision points, quality gates | Process pattern |
| **Orchestration** | Multi-component coordination, state management, routing | Coordination pattern |

See [signal-types.md](references/signal-types.md) for detailed taxonomy.

</signal_identification>

<pattern_classification>

Four primary pattern types:

| Type | Characteristics | Use When |
|------|-----------------|----------|
| **Workflow** | Sequential phases, clear transitions, quality gates | Process has ordered steps |
| **Orchestration** | Coordinates components, manages state, routes work | Multiple actors involved |
| **Heuristic** | Condition → action mapping, context-sensitive | Repeated decisions |
| **Anti-Pattern** | Common mistake, causes rework, has better alternative | Preventing failures |

See [pattern-types.md](references/pattern-types.md) for templates and examples.

</pattern_classification>

<evidence_thresholds>

## Codification Criteria

Don't codify after first occurrence. Require:
- **3+ instances** — minimum repetition to establish pattern
- **Multiple contexts** — works across different scenarios
- **Clear boundaries** — know when to apply vs not apply
- **Measurable benefit** —