# Find Patterns

> This skill should be used when recognizing recurring themes, identifying patterns in work or data, or when pattern, recurring, or repeated are mentioned. For implementation, see codify skill.

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

---


# Pattern Identification

Observe signals → classify patterns → validate with evidence → document findings.

## Steps

1. Collect signals from conversation, code, or data
2. Classify pattern type (workflow, orchestration, heuristic, anti-pattern)
3. Validate against evidence threshold (3+ instances, multiple contexts)
4. Document pattern with constraints and examples
5. If implementation needed, delegate by loading the `codify` skill

<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 stages, 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** — improves outcome compared to ad-hoc approach

## Quality Indicators

| Strong Pattern         | Weak Pattern                |
| ---------------------- | --------------------------- |
| Consistent structure   | Varies each use             |
| Transferable to others | Requires specific expertise |
| Handles edge cases     | Breaks on deviation         |
| Saves time/effort      | Overhead exceeds value      |

</evidence_thresholds>

<progressive_formalization>

**Observation** (1-2 instances):

- Note for future reference
- "This worked well, watch for recurrence"

**Hypothesis** (3+ instances):

- Draft informal guideline
- Test consciously in next case

**Codification** (validated pattern):

- Create formal documentation
- Include examples and constraints

**Refinement** (ongoing):

- Update based on usage
- Add edge cases

</progressive_formalization>

<workflow>

Loop: Observe → Classify → Validate → Document

1. **Collect signals** — note successes, failures, recurring behaviors
2. **Classify pattern type** — workflow, orchestration, heuristic, anti-pattern
3. **Check evidence threshold** — 3+ instances? Multiple contexts?
4. **Extract quality criteria** — what makes it work?
5. **Document pattern** — name, when, what, why
6. **Test deliberately** — apply consciously, track variance
7. **Refine** — adjust based on feedback

</workflow>

<rules>

ALWAYS:

- Require 3+ instances before codifying
- Validate across multiple contexts
- Document both when to use AND when not to
- Include concrete examples
- Track pattern effectiveness over time

NEVER:

- Codify after single occurrence
- Abstract without evidence
- Ignore context-sensitivity
- Skip validation step
- Assume transferability without testing

</rules>

<references>

- [signal-types.md](references/signal-types.md) — detailed signal taxonomy
- [pattern-types.md](references/pattern-types.md) — pattern templates and examples

**Identification vs Implementation**:

- This skill (`patterns`) identifies and documents patterns
- `codify` skill implements patterns as Claude Code components (skills, commands, hooks, agents)

Use `patterns` to answer "what patterns exist?" Use `codify` to answer "how do I turn this into a reusable component?"

</references>