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:codifyskill
<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>
<workflow>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 - •
codifyskill 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?"