explain-feature

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

1. 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.
2. 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.
3. Research the feature using the Claude Code documentation and any relevant project files.
4. 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:

1. A real-world scenario — a concrete situation someone would face
2. What the user does — the action taken (command, config, workflow)
3. 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:

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

Steps

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

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