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 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 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
Deep-dive documentation:
- signal-types.md — detailed signal taxonomy
- pattern-types.md — pattern templates and examples
Related skills:
- patternify — pattern discovery from conversations
- codebase-analysis — uses pattern analysis for code investigation
- report-findings — presenting discovered patterns
More from outfitter-dev/agents
codebase-recon
This skill should be used when analyzing codebases, understanding architecture, or when "analyze", "investigate", "explore code", or "understand architecture" are mentioned.
93graphite-stacks
This skill should be used when the user asks to "create a stack", "submit stacked PRs", "gt submit", "gt create", "reorganize branches", "fix stack corruption", or mentions Graphite, stacked PRs, gt commands, or trunk-based development workflows.
76code-review
This skill should be used when reviewing code before commit, conducting quality gates, or when "review", "fresh eyes", "pre-commit review", or "quality gate" are mentioned.
34hono-dev
This skill should be used when building APIs with Hono, using hc client, implementing OpenAPI, or when "Hono", "RPC", or "type-safe API" are mentioned.
28software-craft
This skill should be used when making design decisions, evaluating trade-offs, assessing code quality, or when "engineering judgment" or "code quality" are mentioned.
28subagents
This skill should be used when coordinating agents, delegating tasks to specialists, or when "dispatch agents", "which agent", or "multi-agent" are mentioned.
25