Agent skill
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.
Install this agent skill to your Project
npx add-skill https://github.com/outfitter-dev/agents/tree/main/plugins/outfitter/skills/patterns
Metadata
Additional technical details for this skill
- version
- 1.1.0
- related skills
-
[ "codify", "codebase-recon", "report-findings" ]
SKILL.md
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>
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?"
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
stack-feedback
Creates GitHub issues for problems discovered while using @outfitter/* packages. Use when finding bugs, missing features, unclear documentation, or improvement opportunities.
stack-architecture
Design stack-based systems using @outfitter/* packages. Use when planning new projects, choosing packages, designing handler architecture, or when "architecture", "design", "structure", "plan handlers", or "error taxonomy" are mentioned.
stack-templates
Templates for creating handlers, CLI commands, MCP tools, and daemon services following Outfitter Stack conventions. Use when scaffolding new components, creating handlers, adding commands, or when "create handler", "new command", "add tool", "scaffold", "template", or "daemon service" are mentioned.
stack-audit
Scan codebase for Outfitter Stack adoption candidates. Identifies throw statements, console usage, hardcoded paths, and custom errors. Use when assessing adoption scope or checking readiness.
stack-review
Audits code for Outfitter Stack compliance including Result types, error handling, logging patterns, and path safety. Use for pre-commit reviews, code quality checks, migration validation, or when "audit", "check compliance", "review stack", or "stack patterns" are mentioned.
stack-patterns
Reference for Outfitter Stack patterns including Result types, Handler contract, Error taxonomy, and @outfitter/* package conventions. Use when learning the stack, looking up patterns, understanding packages, or when "Result", "Handler", "error taxonomy", "OutfitterError", "CLI output", "pagination", "MCP server", "MCP tool", "structured logging", "redaction", "test handler", "daemon", "IPC", or "@outfitter/*" are mentioned.
Didn't find tool you were looking for?