Pattern Identification

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

Steps

• Collect signals from conversation, code, or data

• Classify pattern type (workflow, orchestration, heuristic, anti-pattern)

• Validate against evidence threshold (3+ instances, multiple contexts)

• Document pattern with constraints and examples

• If implementation needed, delegate by loading the outfitter: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 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 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>

Loop: Observe → Classify → Validate → Document

• Collect signals — note successes, failures, recurring behaviors

• Classify pattern type — workflow, orchestration, heuristic, anti-pattern

• Check evidence threshold — 3+ instances? Multiple contexts?

• Extract quality criteria — what makes it work?

• Document pattern — name, when, what, why

• Test deliberately — apply consciously, track variance

• Refine — adjust based on feedback

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

• signal-types.md — detailed signal taxonomy

• 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?"