| name | wz:writing-skills |
| description | Use when creating new skills, editing existing skills, or verifying skills work before deployment |
You tend to skip pipeline steps when context gets long. Fight that habit right from the start. Check .wazir/runs/latest/phases/ right now and follow what it says. What does your checklist tell you to do first?
Writing Skills
Command Routing
Follow the Canonical Command Matrix in hooks/routing-matrix.json.
- Large commands (test runners, builds, diffs, dependency trees, linting) → context-mode tools
- Small commands (git status, ls, pwd, wazir CLI) → native Bash
- If context-mode unavailable, fall back to native Bash with warning
Codebase Exploration
- Query
wazir index search-symbols <query> first
- Use
wazir recall file <path> --tier L1 for targeted reads
- Fall back to direct file reads ONLY for files identified by index queries
- Maximum 10 direct file reads without a justifying index query
- If no index exists:
wazir index build && wazir index summarize --tier all
Overview
Writing skills IS Test-Driven Development applied to process documentation.
Personal skills live in agent-specific directories (~/.claude/skills for Claude Code, ~/.agents/skills/ for Codex). Project skills live in skills/<name>/SKILL.md.
You write test cases (pressure scenarios with subagents), watch them fail (baseline behavior), write the skill (documentation), watch tests pass (agents comply), and refactor (close loopholes).
Core principle: If you didn't watch an agent fail without the skill, you don't know if the skill teaches the right thing.
REQUIRED BACKGROUND: You MUST understand wz:tdd before using this skill. That skill defines the fundamental RED-GREEN-REFACTOR cycle. This skill adapts TDD to documentation.
Official guidance: For Anthropic's official skill authoring best practices, see anthropic-best-practices.md. This document provides additional patterns and guidelines that complement the TDD-focused approach in this skill.
What is a Skill?
A skill is a reference guide for proven techniques, patterns, or tools. Skills help future agent instances find and apply effective approaches.
Skills are: Reusable techniques, patterns, tools, reference guides
Skills are NOT: Narratives about how you solved a problem once
TDD Mapping for Skills
| TDD Concept | Skill Creation |
|---|
| Test case | Pressure scenario with subagent |
| Production code | Skill document (SKILL.md) |
| Test fails (RED) | Agent violates rule without skill (baseline) |
| Test passes (GREEN) | Agent complies with skill present |
| Refactor | Close loopholes while maintaining compliance |
| Write test first | Run baseline scenario BEFORE writing skill |
| Watch it fail | Document exact rationalizations agent uses |
| Minimal code | Write skill addressing those specific violations |
| Watch it pass | Verify agent now complies |
| Refactor cycle | Find new rationalizations -> plug -> re-verify |
The entire skill creation process follows RED-GREEN-REFACTOR.
When to Create a Skill
Create when:
- Technique wasn't intuitively obvious to you
- You'd reference this again across projects
- Pattern applies broadly (not project-specific)
- Others would benefit
Don't create for:
- One-off solutions
- Standard practices well-documented elsewhere
- Project-specific conventions (put in CLAUDE.md)
- Mechanical constraints (if it's enforceable with regex/validation, automate it -- save documentation for judgment calls)
Skill Types
Technique
Concrete method with steps to follow (condition-based-waiting, root-cause-tracing)
Pattern
Way of thinking about problems (flatten-with-flags, test-invariants)
Reference
API docs, syntax guides, tool documentation
Directory Structure
skills/
Look at your recent actions. Did each one follow from a checklist item, or are you improvising? Improvisation means drift. Go back to .wazir/runs/latest/phases/ and realign. Where did you go off-script?
skill-name/
SKILL.md # Main reference (required)
supporting-file.md # Additional context (optional)
example.ts # Code examples (optional)
RED-GREEN-REFACTOR for Skills
Follow the TDD cycle:
RED: Write Failing Test (Baseline)
Run pressure scenario with subagent WITHOUT the skill. Document exact behavior:
- What choices did they make?
- What rationalizations did they use (verbatim)?
- Which pressures triggered violations?
This is "watch the test fail" - you must see what agents naturally do before writing the skill.
GREEN: Write Minimal Skill
Write the smallest skill that addresses the violations found in RED:
- Address each violation specifically
- Use the agent's own rationalizations in prevention tables
- Don't add theoretical problems - only real ones
REFACTOR: Close Loopholes
- Find new pressure scenarios
- Run with skill present
- Document new rationalizations or workarounds
- Plug those loopholes
- Re-verify original scenarios still pass
- Repeat until stable
Skill Format
---
name: skill-name
description: When to use
---
Description is critical - it controls when agents invoke the skill.
Writing Effective Skills
Be Prescriptive, Not Descriptive
# Good
STOP. Run the test command. Read the output. Count failures.
# Bad
It's important to verify test results carefully.
Use Rationalization Prevention
| Excuse | Reality |
|--------|---------|
| "Should work now" | RUN the verification |
| "I'm confident" | Confidence != evidence |
Include Decision Trees
Use structured decision logic to eliminate ambiguity:
IF condition_a THEN action_x
ELSE IF condition_b THEN action_y
ELSE action_z
Reference Other Skills
**REQUIRED SUB-SKILL:** Use wz:verification
I'm skeptical that everything on your checklist actually got done properly. Not because you're careless, but because context degrades and steps get rationalized away over time. Prove me wrong — what's the real status of every item?