patternify
Patternify
Conversation analysis → reusable pattern → correct component.
<when_to_use>
- Spotting repeated behavior worth codifying
- User explicitly wants to capture a workflow
- Recognizing orchestration sequences in conversation
- Identifying decision heuristics being applied
NOT for: one-off tasks, simple questions, well-documented existing patterns
</when_to_use>
<pattern_types>
| Type | Purpose | Example |
|---|---|---|
| Workflow | Multi-step sequences | Debug → Test → Fix → Verify |
| Orchestration | Tool coordination | Git + Linear + PR automation |
| Heuristic | Decision rules | "When X, do Y because Z" |
Workflows: Step-by-step processes with defined phases and transitions. Orchestration: Tool combinations that work together for a goal. Heuristics: Conditional logic and decision trees for common situations.
</pattern_types>
<component_mapping>
Match pattern type to implementation:
Is it a multi-step process with phases?
├─ Yes → Does it need tool restrictions?
│ ├─ Yes → Skill (with allowed_tools)
│ └─ No → Skill
└─ No → Is it a simple entry point?
├─ Yes → Command (thin wrapper → Skill)
└─ No → Is it autonomous/long-running?
├─ Yes → Agent
└─ No → Is it reactive to events?
├─ Yes → Hook
└─ No → Probably doesn't need codifying
Composites:
- Skill + Command: Skill holds logic, command provides entry point
- Skill + Hook: Skill holds logic, hook triggers automatically
- Agent + Skill: Agent orchestrates, skill provides methodology
</component_mapping>
Pattern spec format (YAML):
name: pattern-name
type: workflow | orchestration | heuristic
trigger: when to apply
phases: # workflow
- name: phase-name
actions: [...]
exit_criteria: condition
tools: # orchestration
- tool: name
role: purpose
sequence: order
rules: # heuristic
- condition: when
action: what
rationale: why
quality:
specific: true | false
repeatable: true | false
valuable: true | false
documented: true | false
scoped: true | false
All five quality checks must pass before codifying.
- Identify: Spot repeatable behavior in conversation
- For deep analysis, load codebase-recon skill and use patterns techniques
- Extract success, frustration, workflow, and request signals
- Look for 3+ occurrences of similar behavior
- Classify: Workflow, Orchestration, or Heuristic?
- Map: Which component(s) should implement it?
- Specify: Document with pattern spec format
- Quality: Validate against SRVDS criteria
- Implement: Create the component(s)
Task phases:
- Identify { pattern description }
- Classify { pattern type }
- Map { component decision }
- Specify { pattern name }
- Implement { component type }
SRVDS criteria — all must pass:
| Check | Question | Red Flag |
|---|---|---|
| Specific | Clear trigger + scope? | "Sometimes useful" |
| Repeatable | Works across contexts? | One-off solution |
| Valuable | Worth the overhead? | Saves < 5 minutes |
| Documented | Can others understand? | Tribal knowledge |
| Scoped | Single responsibility? | Kitchen sink |
Skip if: < 3 occurrences, context-dependent, simpler inline
<anti_patterns>
- Premature abstraction: Codifying after first occurrence
- Over-specification: 50-line spec for 5-line pattern
- Wrong component: Hook when Skill needed, Agent when Command suffices
- Missing trigger: Pattern exists but no clear activation
- Scope creep: Pattern grows to handle edge cases
</anti_patterns>
ALWAYS:
- Identify pattern type before choosing component
- Validate all SRVDS criteria
- Start with minimal implementation
- Document trigger conditions clearly
- Test pattern in at least 2 contexts
NEVER:
- Codify after single occurrence
- Create Agent when Skill suffices
- Skip quality validation
- Implement without clear trigger
- Add "might need later" features
- codebase-recon — core investigation methodology
- patterns — signal extraction techniques
- pattern-types.md — extended examples by type
- component-mapping.md — decision tree details
- examples/ — captured pattern examples
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.
92hono-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.
28claude-rules
This skill should be used when creating rule files, organizing conventions, or when ".claude/rules/", "FORMATTING.md", "create rule", or "project conventions" are mentioned.
21react-dev
This skill should be used when building React components with TypeScript, typing hooks, handling events, or when React TypeScript, React 19, Server Components are mentioned. Covers type-safe patterns for React 18-19 including generic components, proper event typing, and TanStack Router integration.
17architecture
This skill should be used when designing systems, evaluating architectures, making technology decisions, or planning for scale. Provides technology selection frameworks, scalability planning, and architectural tradeoff analysis.
15research
This skill should be used when researching best practices, evaluating technologies, comparing approaches, or when "research", "evaluation", or "comparison" are mentioned.
15