Extension Authoring

1. Skills - Modular capabilities in SKILL.md files that provide domain expertise
2. Hooks - Event-driven automation that executes on tool use and session events
3. Slash Commands - Reusable prompts triggered with /command-name syntax
4. Subagents - Specialized Claude instances for delegated tasks

All four extension types share core principles: pure XML structure, YAML frontmatter, and clear success criteria. This skill teaches you to create effective extensions following best practices.

1. Skill - SKILL.md file for domain expertise
2. Hook - Event-driven automation (PreToolUse, PostToolUse, Stop, etc.)
3. Slash Command - Reusable prompt with /command-name
4. Subagent - Specialized agent for delegated tasks
5. Guidance - Help deciding which extension type to use

Respond with a number or describe what you want to build.

After reading the reference, follow its workflow exactly.

Is it triggered by specific Claude Code events?
  (tool use, session start/end, user prompt submit)
    YES --> Hook

Is it a reusable prompt the user invokes with /command-name?
    YES --> Slash Command

Is it an isolated task that runs autonomously without user interaction?
    YES --> Subagent

Is it domain knowledge or workflow guidance Claude loads on demand?
    YES --> Skill

Quick decision matrix:

<objective>What it does</objective>
<workflow>How to do it</workflow>
<success_criteria>How to know it worked</success_criteria>

Keep markdown formatting WITHIN content (bold, lists, code blocks).

Why XML?

• Semantic meaning for Claude (not just visual formatting)
• Unambiguous section boundaries
• Token efficient (~15 tokens vs ~20 for markdown headings)
• Reliable parsing and progressive disclosure

---
name: extension-name       # lowercase-with-hyphens
description: What it does and when to use it (third person)
---

Name conventions: create-*, manage-*, setup-*, generate-*

Description rules:

• Third person (never "I" or "you")
• Include WHAT it does AND WHEN to use it
• Maximum 1024 characters

• Assume Claude is smart
• Challenge every piece of content: "Does this justify its token cost?"
• Provide default approach with escape hatch, not a list of options
• Keep main files under 500 lines, split to reference files

<success_criteria>
- Specific measurable outcome 1
- Specific measurable outcome 2
- How to verify it worked
</success_criteria>

Minimal examples:

Extract text from PDF files using pdfplumber.

Text extracted without errors.

</skill_example>

<hook_example>
```json
{
  "hooks": {
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Claude needs input\" with title \"Claude Code\"'"
          }
        ]
      }
    ]
  }
}

Create a git commit for current changes.

Commit created successfully.

</command_example>

<subagent_example>
```markdown
---
name: code-reviewer
description: Reviews code for quality and security. Use after code changes.
tools: Read, Grep, Glob, Bash
model: sonnet
---

<role>
You are a senior code reviewer focused on quality and security.
</role>

<workflow>
1. Read modified files
2. Identify issues
3. Provide specific feedback with file:line references
</workflow>

<constraints>
- NEVER modify code, only review
- ALWAYS provide actionable feedback
</constraints>

<good>Using XML tags instead</good>

• Valid YAML frontmatter with descriptive name and description
• Pure XML structure (no markdown headings in body)
• Clear objective/purpose statement
• Defined success criteria or completion verification
• Appropriate level of detail (not over-engineered)
• Real-world testing and iteration
• Documentation in third person