codify

name	codify
description	This skill should be used when implementing patterns as Claude Code components (skills, commands, hooks, agents), or when codify, capture workflow, turn into a skill, or make reusable are mentioned. For pattern identification, see find-patterns skill.
agent	analyst
context	fork
metadata	{"version":"1.3.1","related-skills":["find-patterns","claude-craft"]}

Codify

Identified pattern → component mapping → implementation.

<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 stages 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 stages?
├─ 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
stages: # workflow
  - name: stage-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  

All five quality checks must pass before codifying.

1. Identify: Spot repeatable behavior in conversation
   • If hint/argument provided, focus analysis on that specific pattern
   • Otherwise scan for: workflows, orchestrations, and heuristics worth capturing
   • For deep analysis, load codebase-analysis skill and use find-patterns techniques
   • Extract success, frustration, workflow, and request signals
   • Look for 3+ occurrences of similar behavior
2. Classify: Workflow, Orchestration, or Heuristic?
3. Map: Which component(s) should implement it?
4. Specify: Document with pattern spec format
5. Quality: Validate against SRVDS criteria
6. Implement: Create the component(s)

Task stages:

- 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

• pattern-types.md — extended examples by type
• component-mapping.md — decision tree details
• examples/ — captured pattern examples

Identification vs Implementation:

• find-patterns skill identifies and documents patterns
• This skill (codify) implements patterns as Claude Code components

Use find-patterns first to identify what's worth capturing. Use codify to turn identified patterns into skills, commands, hooks, or agents.

Component skills (loaded during implementation):

• claude-craft — agents, commands, hooks, skills, rules, and config