claude-code:skill
npx machina-cli add skill bendrucker/claude/skill --openclawClaude Code Skills Development
Reference for developing effective skills. The context window is a public good - only include information Claude doesn't already possess.
Core Principles
- Conciseness: Keep
SKILL.mdunder 500 lines. Use progressive disclosure. - Appropriate Freedom: Text for flexible tasks, pseudocode for moderate variation, scripts for error-prone operations.
- Cross-Model Testing: Validate across Haiku, Sonnet, and Opus.
Skill Structure
---
name: plugin-name:skill-name
description: Third-person capability description with trigger terms
allowed-tools: [Read, Grep, Glob] # Optional: tool restrictions
model: claude-sonnet-4-20250514 # Optional: override model
context: fork # Optional: run in isolated subagent
agent: Explore # Optional: agent type for fork
user-invocable: false # Optional: hide from slash menu
hooks: # Optional: skill-scoped hooks
PreToolUse:
- matcher: "Bash"
hooks:
- type: command
command: "./scripts/validate.sh"
once: true
---
Required Fields:
name: Lowercase letters, numbers, hyphens only (max 64 chars). Plugin skills useplugin-name:skill-nameprefix for disambiguation. Skip the prefix when name equals plugin name.description: Third-person, includes trigger terms and use cases (max 1024 chars).
Optional Fields:
allowed-tools: Tools Claude can use without permission when skill is activemodel: Override the conversation's modelcontext: Set toforkto run in isolated subagent contextagent: Agent type whencontext: fork(Explore,Plan,general-purpose, or custom)user-invocable: Hide from slash menu whenfalse(default:true)disable-model-invocation: Block programmatic invocation via Skill toolhooks: Skill-scoped hooks (PreToolUse,PostToolUse,Stop)
Naming: Plugin skills use plugin-name:skill-name with a colon namespace (e.g., gitlab:ci, things:inbox). The part after the colon should not repeat the plugin name. For standalone skills, use gerund form (verb + -ing): processing-pdfs, analyzing-data. Avoid vague names like helper, utils.
Storage: ~/.claude/skills/ (personal), .claude/skills/ (project), plugins (bundled)
Content Features
String Substitutions
| Variable | Description |
|---|---|
$ARGUMENTS | All arguments passed when invoking the skill. Appended automatically if absent. |
$ARGUMENTS[N] / $N | Access a specific argument by 0-based index. |
${CLAUDE_SESSION_ID} | Current session ID. |
${CLAUDE_SKILL_ROOT} | Absolute path to the skill's directory. Works in hooks and allowed-tools, but NOT in ! context. |
Dynamic Context Injection
The bang-backtick syntax runs shell commands before the skill content is sent to Claude. The command output replaces the placeholder — Claude only sees the final result, not the command. This is preprocessing, not something Claude executes. Use this to inject live data (git state, CLI output, file contents) so the application harness extracts and runs the commands without waiting on the model.
See references/patterns.md for syntax, examples, and gotchas.
Directory Structure
Skills follow the Agent Skills directory convention. Only SKILL.md is required; all directories are optional.
skill-name/
├── SKILL.md # Required: instructions and frontmatter
├── scripts/ # Executable code agents can run
├── references/ # Documentation loaded on demand
└── assets/ # Static resources (templates, images, data files)
A PostToolUse hook validates writes to skill directories against this structure.
scripts/
Executable code that agents run. Scripts should be self-contained, document dependencies, and include error messages.
references/
Additional documentation loaded when needed. Keep files focused — smaller files mean less context usage. Use descriptive names matching the domain (finance.md, api.md).
assets/
Static resources: templates, images, diagrams, lookup tables, schemas.
File Naming
Reserve ALL CAPS for files with special meaning (SKILL.md, README.md). Use lowercase for all other files. Keep references one level deep. For files >100 lines, include a table of contents.
Development Process
- Define 3 test scenarios before documentation
- Measure baseline without skill
- Iterative: one instance creates, another tests
- Observe navigation patterns
- Refine based on behavior
Validation
Run bun run skill-lint path/to/skill/ to check for issues before committing. CI runs this automatically.
References
Load detailed guides as needed:
- references/patterns.md - Dynamic context injection, argument substitutions, progressive disclosure, workflows, subagent integration
- references/troubleshooting.md - Activation issues, YAML errors, plugin cache, checklist
Quick Reference
Common Patterns: Read-only ([Read, Grep, Glob]), Script-based ([Read, Bash, Write]), Template-based ([Read, Write, Edit])
Content Features: $ARGUMENTS / $N for arguments, bang-backtick for dynamic context injection
Anti-Patterns: Windows paths, too many options, vague descriptions, nested references, scripts that punt errors
Resources
Source
git clone https://github.com/bendrucker/claude/blob/main/plugins/claude-code/skills/skill/SKILL.mdView on GitHub Overview
Claude Code Skills Development provides a framework for building effective Claude Code skills, focusing on activation patterns, content structure, and development workflows. It emphasizes concise SKILL.md practices, appropriate task granularity, and cross-model validation. The guide covers naming, storage, hooks, and dynamic context features to ensure robust skills.
How This Skill Works
Skills are defined with structured fields (name, description, allowed-tools, hooks, etc.) and optional parameters (model, context, agent). They leverage PreToolUse and PostToolUse hooks, plus dynamic context injection via bang-backtick to run commands before content is sent to Claude. Built-in checks (check-namespace.ts and check-structure.ts) validate structure after tool usage to catch errors early.
When to Use It
- Creating a brand-new Claude Code skill from scratch
- Converting memory files into a formal skill package
- Debugging skill activation and hook failures
- Aligning a skill with core principles (conciseness, testing, naming, storage)
- Planning skill structure and storage for projects/plugins
Quick Start
- Step 1: Create a SKILL.md with name and description using lowercase names and trigger terms; ensure description stays within 1024 chars.
- Step 2: Add optional fields (allowed-tools, model, context, agent) and define hooks (PreToolUse, PostToolUse) as needed; set storage per guidelines.
- Step 3: Run the built-in checks: bun ${CLAUDE_SKILL_ROOT}/scripts/check-namespace.ts and bun ${CLAUDE_SKILL_ROOT}/scripts/check-structure.ts to validate the skill.
Best Practices
- Keep SKILL.md under 500 lines and use progressive disclosure
- Use the 3-tier content approach: concise tasks, pseudocode for variations, scripts for error-prone ops
- Validate across Haiku, Sonnet, and Opus to ensure cross-model consistency
- Follow naming conventions and storage guidelines for plugin vs standalone skills
- Leverage hooks and dynamic context injection to improve reliability and reproducibility
Example Use Cases
- gitlab:ci — a plugin skill skeleton for GitLab CI integration
- analyzing-data — a standalone skill that analyzes datasets
- processing-pdfs — a standalone skill to process PDFs with dynamic content
- things:inbox — a plugin-based content organization skill
- claude-code:skill — internal example illustrating governance and structure