explain-feature - SKILL.md Agent Skill

name: explain-feature description: Explain a specific Claude Code feature in detail. Use when the user asks any question about Claude Code features, capabilities, or how things work — even in casual conversation. Always generate documentation. argument-hint: [feature-name] allowed-tools: Read, Write, Grep, Glob, WebSearch, WebFetch, Agent

Explain Claude Code Feature

The user wants to understand the Claude Code feature: $ARGUMENTS

Instructions

Identify the feature from the argument or from the user's question. Match it against the known Claude Code feature categories below. If the user asked a general question (e.g., "how do hooks work?"), derive the feature name from the topic.
Check for an existing document using Glob("docs/features/*.md"). If a file already covers this feature (e.g., 09-memory.md for "memory"), update that file rather than creating a new one.
Research the feature using the Claude Code documentation and any relevant project files.
Write or update the markdown document (see Output Format) with:
- Feature name and one-line summary
- What it does and why it matters
- How to use it (syntax, commands, configuration)
- Practical use cases with concrete examples (see format below)
- Tips and best practices
- Related features
- Sources (URLs or documents consulted during research)

Known Feature Categories

tools: Built-in tools (Read, Edit, Write, Bash, Grep, Glob, Agent, etc.)
skills: Custom skills in .claude/skills/ — creation, invocation, frontmatter
hooks: Event-driven shell commands (PreToolUse, PostToolUse, Notification, etc.)
mcp: Model Context Protocol servers — configuration and usage
memory: Persistent memory system in .claude/projects/
permissions: Permission modes (default, acceptEdits, bypassPermissions, plan, auto)
agents: Subagent system (Explore, Plan, general-purpose, custom agents)
plans: Plan mode for designing implementation strategies
tasks: Task management (TaskCreate, TaskUpdate, TaskList)
context: Context management, compression, and window optimization
git: Git integration (commits, PRs, branches, status)
settings: Configuration via settings.json, settings.local.json, CLAUDE.md
keybindings: Keyboard shortcut customization
ide: IDE integrations (VS Code, JetBrains)
slash-commands: Built-in slash commands (/help, /clear, /compact, /fast, etc.)
worktrees: Git worktree isolation for parallel work
crons: Scheduled remote agents / triggers
models: Model selection and configuration (Opus, Sonnet, Haiku)

Output Format

IMPORTANT: You MUST always write or update a markdown file in docs/features/, even if the user asked a casual question. Every Claude Code question should result in a saved document.

Document Header

Every document must include a metadata block at the top (after the H1 title):

# Feature Name

**Version:** 1.0
**Date:** YYYY-MM-DD
**One-line summary:** ...

Version: Start at 1.0 for new documents. Increment by 0.1 for minor additions, 1.0 for major rewrites.
Date: Creation date — set once, never changed.
Updated: Today's date — add this field when updating an existing document.

When updating an existing document, increment the version and add/update the **Updated:** field.

Practical Use Cases Section

Every document must include a ## Practical Use Cases section with 2–4 realistic scenarios. Each use case must show:

A real-world scenario — a concrete situation someone would face
What the user does — the action taken (command, config, workflow)
What Claude does / what happens — the outcome

Format:

## Practical Use Cases

### Use Case 1: <Short Title>

**Scenario:** You're starting a new project and want Claude to always use `pnpm` instead of `npm`.

**What you do:**
Tell Claude: "Always use pnpm, not npm."

**What happens:**
Claude saves a feedback memory:
\```markdown
---
name: feedback-package-manager
type: feedback
---
Always use pnpm, not npm.
**Why:** User preference.
**How to apply:** Any time package installation is needed.
\```

In future sessions, Claude automatically reaches for `pnpm` without being reminded.

Use realistic, specific examples. Avoid vague or generic descriptions. Code blocks, file contents, and before/after comparisons are encouraged.

Sources Section

Every document must end with a ## Sources section listing all references consulted:

## Sources

- [Title](URL) — one-line description of what this source covers
- [Official Docs: Feature Name](URL)
- Internal: `path/to/file.md` — brief note on what was found there

Include both web sources (documentation, blog posts, release notes) and internal files read during research. When updating a document, append new sources rather than replacing existing ones.

File Naming (new documents only)

Documents are numbered to track creation order. Before creating a new file:

Use Glob("docs/features/*.md") to list existing files.
Check if any existing file already covers the feature — if so, update it instead.
If truly new: find the highest existing index prefix (e.g., if 10-auto-dream.md exists, next is 11).
Name the new file <index>-$0.md (zero-padded to 2 digits, e.g., 11-hooks.md).

Steps

Glob existing docs; determine whether to update or create.
Write or update the document with the correct version and date.
Update docs/claude-code-features.md if the topic adds new information not already covered.
Provide a brief summary to the user with the key points.

This ensures the knowledge base grows in order and stays up to date.