writing-cli-skills
Writing CLI Skills
How to write an agent skill for a command-line tool.
Quick Start
- Install the tool and play with it — don't just read docs. If the tool is unavailable, use WebFetch on official docs + man pages, but note this in your skill as "not hands-on verified"
- Run
--helpon every subcommand - Try the common operations yourself
- Note what surprises you or isn't obvious
- Copy
references/template.mdto your new skill directory - Fill in sections based on your hands-on experience
- Delete sections that don't apply
# First: actually use the tool
my-tool --help
my-tool subcommand --help
my-tool do-something # try it!
# Then: create the skill
# This will depend on the tool
# Claude Code
ln -s "$PWD/skills/my-tool" ~/.claude/skills/my-tool
# OpenCode
ln -s "$PWD/skills/my-tool" ~/.config/opencode/skills/my-tool
# Clawdbot
ln -s "$PWD/skills/my-tool" ~/clawd/skills/my-tool
Reading docs is no substitute for hands-on use. You'll discover defaults, gotchas, and real behavior that docs don't mention.
What NOT to Do
- Do not dump
--helpoutput verbatim — summarize the useful parts - Do not document every flag — focus on the 80% use cases
- Do not include commands you haven't tested
- Do not exceed 500 lines — this bloats agent context windows
Sections
Required
Every CLI skill needs at minimum:
| Section | Purpose |
|---|---|
| Frontmatter | name, description (with trigger phrases) |
| Installation | How to get the binary |
| Usage | The 80% use cases |
Recommended
| Section | When to Include |
|---|---|
| Requirements | Tool needs accounts, API keys, or dependencies |
| Quick Start | Tool has a simple "happy path" |
| Output Formats | Tool can output JSON or custom formats |
| Tips & Gotchas | Tool has some edge cases or things an agentic LLM should not use |
| Troubleshooting | Tool has debug modes or common failure modes |
| Configuration | Tool has config files or env vars |
| Uninstall | Tool leaves config/data behind |
| References | When there are useful docs or content that contains more details |
Writing Good Descriptions
Include trigger phrases so the agent knows when to load the skill:
# Good
description: Monitor RSS feeds for updates. Use when tracking blogs, checking for new posts, or building a feed reader workflow.
# Bad
description: RSS tool.
Organizing Commands
Group by task, not by command name:
## Usage
### View / List
### Create / Add
### Edit / Update
### Delete / Remove
### Search
Progressive Disclosure
Keep SKILL.md under ~500 lines. Move details to references/:
my-tool/
├── SKILL.md # Core usage
├── references/
│ ├── advanced-config.md # Deep config docs
│ └── api-reference.md # API details
└── scripts/
└── helper.sh # Helper scripts
Frontmatter Reference
---
name: tool-name # Required, matches directory
description: What + when # Required, include triggers
---
Checklist
Before publishing a CLI skill:
- Frontmatter has name + description with trigger phrases
- Installation covers target platforms
- Includes verification command (
tool --version) - Config file locations documented
- Required env vars listed
- Common operations in usage cover 80% of use cases
- Examples show realistic usage with sample output
- Output formats documented (if tool supports JSON/etc)
- Troubleshooting includes debug mode
- Uninstall cleans up config and data
- Under 500 lines (details in references/)
Template
See references/template.md for a complete starting point.
More from cachemoney/agent-toolkit
coolify-compose
Convert Docker Compose files to Coolify templates. Use when creating Coolify services, converting docker-compose.yml for Coolify deployment, working with SERVICE_URL/SERVICE_PASSWORD magic variables, or troubleshooting Coolify compose errors.
23diataxis
Structure, classify, and write documentation using the Diátaxis framework. Use when writing docs, README files, guides, tutorials, how-to guides, API references, or organizing documentation architecture. Also use when asked to improve documentation, restructure docs, decide what type of doc to write, or classify existing content. Covers tutorials, how-to guides, reference, and explanation.
9backend-to-frontend-handoff-docs
Create API handoff documentation for frontend developers. Use when backend work is complete and needs to be documented for frontend integration, or user says 'create handoff', 'document API', 'frontend handoff', or 'API documentation'.
9requirements-clarity
Clarify ambiguous requirements through focused dialogue before implementation. Use when requirements are unclear, features are complex (>2 days), or involve cross-team coordination. Ask two core questions - Why? (YAGNI check) and Simpler? (KISS check) - to ensure clarity before coding.
9researching-codebases
Use when answering complex questions about a codebase that require exploring multiple areas or understanding how components connect - coordinates parallel sub-agents to locate, analyze, and synthesize findings
9jj
Jujutsu (jj) — the Git-compatible version control system. Activate ONLY when a .jj/ directory is present in the project or when jj/jujutsu is explicitly mentioned. Do NOT activate for plain git repos without .jj/. Use for any VCS operations in jj-managed projects: commit, push, pull, branch, bookmark, rebase, squash, merge, diff, log, status, working copy, change ID, revset, fileset, template, configuration, workspaces.
9