Agent skill
codify
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 patterns skill.
Install this agent skill to your Project
npx add-skill https://github.com/outfitter-dev/agents/tree/main/plugins/outfitter/skills/codify
Metadata
Additional technical details for this skill
- version
- 1.3.0
- related skills
-
[ "patterns", "claude-skills", "claude-commands", "claude-hooks", "claude-agents" ]
SKILL.md
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 | false
All five quality checks must pass before codifying.
- 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
outfitter:codebase-reconskill and useoutfitter:patternstechniques - 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 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:
patternsskill identifies and documents patterns- This skill (
codify) implements patterns as Claude Code components
Use 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-skills— skill authoringclaude-commands— command authoringclaude-hooks— hook authoringclaude-agents— agent authoring
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?