---
name: your-skill-name
description: Brief description of what this skill does and when Claude should use it.
allowed-tools: Read, Grep, Glob
argument-hint: <arg1> <arg2>
model: haiku
---

# Slash Command Template

> Base template for creating consistent, well-structured slash commands.
> Copy this template and fill in each section for your new command.

---

## 0. Front Matter (Required)

<!--
CRITICAL: Front matter MUST be on lines 1-5 of the file, before any markdown content.
The YAML block is separated by --- delimiters and contains metadata for Claude Code.
-->

### Required Fields

**`name`** (required)
- Skill identifier - must use **lowercase letters, numbers, and hyphens only**
- No underscores, spaces, or uppercase letters allowed
- Maximum 64 characters
- Must match the directory name
- Example: `generating-commit-messages`, `pdf-processing`

**`description`** (required)
- What the Skill does and when Claude should use it
- Maximum 1024 characters
- **This is how Claude decides when to trigger your Skill** - be specific!
- Should answer:
  1. What does this Skill do? (list specific capabilities)
  2. When should Claude use it? (include trigger terms users would say)
- Example: "Generate atomic commit plans following TDD workflow. Use when planning implementation of user stories or breaking down complex features into testable increments."

### Optional Fields

**`allowed-tools`** (optional)
- Comma-separated list of tools Claude can use without permission
- Example: `Read, Grep, Glob` or `Read, Bash(python:*)`
- Use to restrict capabilities for read-only or security-sensitive Skills
- Omit if no restrictions needed

**`model`** (optional)
- Specific Claude model to use when this Skill is active
- Format: full model ID (e.g., `claude-sonnet-4-20250514`)
- Omit to use the conversation's current model

### Front Matter Example

```yaml
---
name: pdf-processing
description: Extract text, fill forms, merge PDFs. Use when working with PDF files, forms, or document extraction.
allowed-tools: Read, Bash(python:*)
model: claude-sonnet-4-20250514
---
```

### Critical Formatting Rules

- Start with `---` on **line 1** (no blank lines before it)
- End with `---` before markdown content begins
- Use **spaces for indentation** (not tabs)
- Field names must be lowercase with hyphens (not underscores)
- Invalid YAML prevents the Skill from loading (use `claude --debug` to check)

---

## 1. Identity

<!--
Define the role/expertise the AI should adopt for this command.
This primes the model's attention and activates relevant knowledge.
Keep to 1-2 sentences.
-->

You are a [ROLE] with expertise in [DOMAIN].

---

## 2. Mission

<!--
Single, clear statement of the command's success outcome.
Use outcome language ("Generate X", "Validate Y"), not process language ("Help with").
One sentence only - this prevents scope creep.
-->

[ACTION VERB] [DELIVERABLE] that [SUCCESS CRITERIA].

---

## 3. Inputs

<!--
Explicit parameters the command accepts.
Separate required from optional. Include types and defaults.
This creates a contract between user and template.
-->

### Required
| Parameter | Type | Description |
|-----------|------|-------------|
| `param_name` | string | Description of what this parameter provides |

### Optional
| Parameter | Type | Default | Description |
|-----------|------|---------|-------------|
| `param_name` | boolean | `false` | Description of optional behavior |

---

## 4. Prerequisites

<!--
What must exist or be true before this command can execute.
Fail-fast: if these aren't met, stop and inform the user.
-->

- [ ] Required file/resource exists: `path/to/resource`
- [ ] Prior step completed: [describe dependency]
- [ ] Environment requirement: [describe state]

---

## 5. Guardrails

<!--
Explicit constraints on what NOT to do.
These are non-negotiable boundaries that prevent scope creep and errors.
Separate from workflow - negatives deserve their own section.
-->

### Never
- NEVER [prohibited action 1]
- NEVER [prohibited action 2]

### Always
- ALWAYS [required behavior 1]
- ALWAYS [required behavior 2]

### Boundaries
- Scope is limited to: [explicit boundary]
- Do not modify: [protected resources]

---

## 6. Workflow

<!--
Sequential steps to execute the command.
Use numbered steps for order, bullets for parallel/sub-tasks.
Include decision points with IF/THEN notation.
Each step should be atomic and verifiable.
-->

### Step 1: [Action Name]
- Sub-task or detail
- Sub-task or detail

### Step 2: [Action Name]
- Sub-task or detail

**IF** [condition] **THEN**:
- Alternative action

### Step 3: [Action Name]
- Sub-task or detail

---

## 7. Quality Gates

<!--
Pass/fail validation criteria checked BEFORE marking complete.
This is the command's own acceptance criteria.
Prevents "technically complete but actually broken" outcomes.
-->

Before finalizing, verify ALL of the following:

- [ ] [Measurable criterion 1]
- [ ] [Measurable criterion 2]
- [ ] [Measurable criterion 3]

**If any gate fails:** [Specify recovery action - fix and re-check, or stop and report]

---

## 8. Output

<!--
Exact specification of deliverables.
Include format, location, and structure.
Use templates where possible for consistency.
-->

### Deliverable: [Artifact Name]

**Location:** `path/to/output`
**Format:** markdown | yaml | json | [other]

```[format]
[Template or example of expected output structure]
```

### Console Output

[Describe what the user sees when command completes successfully]

---

## 9. Error Handling

<!--
Optional but recommended for complex commands.
Define known failure modes and recovery actions.
Tells the AI when to stop and ask rather than guess.
-->

### Blocking Conditions
Stop execution and request clarification if:
- [Condition that requires user input]
- [Ambiguous state that can't be resolved]

### Recovery Actions
| Error | Recovery |
|-------|----------|
| [Error type 1] | [How to recover] |
| [Error type 2] | [How to recover] |

---

## Template Usage Notes

### Section Requirements
| Section | Required | Notes |
|---------|----------|-------|
| Identity | Yes | Primes model behavior |
| Mission | Yes | Defines success |
| Inputs | Yes | Even if empty, state "None required" |
| Prerequisites | If applicable | Omit if no dependencies |
| Guardrails | Recommended | Prevents common failures |
| Workflow | Yes | The core execution plan |
| Quality Gates | Yes | Critical for reliability |
| Output | Yes | Defines "done" |
| Error Handling | Optional | Add for complex commands |

### Best Practices
1. **One Mission only** - If you need multiple outcomes, create multiple commands
2. **Guardrails before Workflow** - Set boundaries before describing actions
3. **Quality Gates are assertions** - They validate, not execute
4. **Be specific in Output** - Vague outputs lead to inconsistent results
5. **Test your command** - Run it on edge cases before publishing
