majiayu000 Patternify
Conversation analysis → reusable pattern → correct component.
- 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
| 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.
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
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-analysis skill and use pattern-analysis 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)
TodoWrite 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
- 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
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-analysis — core investigation methodology
- pattern-analysis — signal extraction techniques
- pattern-types.md — extended examples by type
- component-mapping.md — decision tree details
- examples/ — captured pattern examples