Writing Skills

What This Skill Does

This skill applies Test-Driven Development (TDD) principles to the creation of process documentation for agents. It involves writing test cases (pressure scenarios with subagents), observing failures, writing the skill (documentation), verifying successes, and refactoring. It is designed to help create effective and reliable skills for agents.

When to Use

• Create reusable techniques for agents.
• Document proven patterns and tools.
• Develop reference guides for agents.
• Apply TDD principles to documentation.
• Test skills with subagent pressure scenarios.
• Refactor skills to close loopholes.

Key Features

• Applies TDD to process documentation.
• Uses subagents for pressure scenarios.
• Emphasizes watching agents fail before writing skills.
• Requires understanding of superpowers:test-driven-development.
• Provides a TDD mapping for skill creation.
• Links to Anthropic's official skill authoring best practices.

Manual Installation

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)

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 superpowers:test-driven-development 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 Claude 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

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 (office docs)

Directory Structure

skills/ skill-name/ SKILL.md # Main reference (required) supporting-file.* # Only if needed

Flat namespace - all skills in one searchable namespace

Separate files for: Heavy reference (100+ lines) - API docs, comprehensive syntax Reusable tools - Scripts, utilities, templates

Keep inline: Principles and concepts Code patterns (< 50 lines) Everything else

SKILL.md Structure

Frontmatter (YAML): Only two fields supported: name and description Max 1024 characters total name: Use letters, numbers, and hyphens only (no parentheses, special chars) description: Third-person, describes ONLY when to use (NOT what it does)

• Start with "Use when..." to focus on triggering conditions
• Include specific symptoms, situations, and contexts
• NEVER summarize the skill's process or workflow (see CSO section for why)
• Keep under 500 characters if possible

---

name: Skill-Name-With-Hyphens description: Use when [specific triggering conditions and symptoms]

Skill Name

Overview

What is this? Core principle in 1-2 sentences.

When to Use

[Small inline flowchart IF decision non-obvious]

Bullet list with SYMPTOMS and use cases When NOT to use

Core Pattern (for techniques/patterns)

Before/after code comparison

Quick Reference

Table or bullets for scanning common operations

Implementation

Inline code for simple patterns Link to file for heavy reference or reusable tools

Common Mistakes

What goes wrong + fixes

Real-World Impact (optional)

Concrete results

Claude Search Optimization (CSO)

Critical for discovery: Future Claude needs to FIND your skill

1. Rich Description Field

Purpose: Claude reads description to decide which skills to load for a given task. Make it answer: "Should I read this skill right now?"

Format: Start with "Use when..." to focus on triggering conditions

CRITICAL: Description = When to Use, NOT What the Skill Does

The description should ONLY describe triggering conditions. Do NOT summarize the skill's process or workflow in the description.

Why this matters: Testing revealed that when a description summarizes the skill's workflow, Claude may follow the description instead of reading the full skill content. A description saying "code review between tasks" caused Claude to do ONE review, even though the skill's flowchart clearly showed TWO reviews (spec compliance then code quality).

When the description was changed to just "Use when executing implementation plans with independent tasks" (no workflow summary), Claude correctly read the flowchart and followed the two-stage review process.

The trap: Descriptions that summarize workflow create a shortcut Claude will take. The skill body becomes documentation Claude skips.

❌ BAD: Summarizes workflow - Claude may follow this instead of reading skill

description: Use when executing plans - dispatches subagent per task with code review between tasks

❌ BAD: Too much process detail description: Use for TDD - write test first, watch it fail, write minimal code, refactor

✅ GOOD: Just triggering conditions, no workflow summary description: Use when executing implementation plans with independent tasks in the current session

✅ GOOD: Triggering conditions only description: Use when implementing any feature or bugfix, before writing implementation code

Content: Use concrete triggers, symptoms, and situations that signal this skill applies Describe the problem (race conditions, inconsistent behavior) not language-specific symptoms (set Timeout, sleep) Keep triggers technology-agnostic unless the skill itself is technology-specific If skill is technology-specific, make that explicit in the trigger Write in third person (injected into system prompt) NEVER summarize the skill's process or workflow

❌ BAD: Too abstract, vague, doesn't include when to use

description: For async testing

❌ BAD: First person description: I can help you with async tests when they're flaky

❌ BAD: Mentions technology but skill isn't specific to it description: Use when tests use set Timeout/sleep and are flaky

✅ GOOD: Starts with "Use when", describes problem, no workflow description: Use when tests have race condition