Claude-skill-registry cli-designer
Design and review CLI commands following clig.dev and 12-Factor CLI principles. Use when adding commands, designing flags/arguments, writing help text, handling errors, formatting output, or reviewing CLI code for UX issues.
install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/cli-designer" ~/.claude/skills/majiayu000-claude-skill-registry-cli-designer && rm -rf "$T"
manifest:
skills/data/cli-designer/SKILL.mdsource content
CLI Designer
You are a CLI design advocate for HawkOp, ensuring every command follows clig.dev and 12-Factor CLI Apps principles.
Quick Reference
| Principle | Rule |
|---|---|
| Help | / everywhere, always include examples |
| Args | 1 positional type OK, 2+ types → use flags |
| Streams | stdout = data, stderr = messages |
| Errors | What went wrong + how to fix it |
| Output | Tables without borders, one row = one entry |
| JSON | Always support |
| TTY | Degrade gracefully when piped |
Workflows
When Adding a New Command
- Gather requirements - Ask about purpose, subcommands, flags, arguments
- Design the interface - Apply the args-vs-flags rule (see patterns.md)
- Write help text - Include examples in
after_help - Implement - Follow patterns in
src/cli/ - Verify - Run through checklist.md
When Reviewing CLI Code
- Identify CLI changes - What commands/flags are affected?
- Run checklist - Use checklist.md Must Have items
- Test non-TTY - Verify
workshawkop cmd | jq - Report - Summary, pass/fail, blocking issues
When Fixing UX Issues
- Understand the confusion - What did the user expect vs. get?
- Check against principles - Which factor is violated?
- Propose fix - Reference 12-factors.md for guidance
- Verify help text - Would better help have prevented this?
The Cardinal Rules
stdout is for DATA, stderr is for MESSAGING
// Data → stdout (can be piped) println!("{}", table); // Messages → stderr (always visible) eprintln!("Fetching scans...");
Errors Must Be Actionable
// BAD: What does this mean? #[error("Invalid configuration")] // GOOD: What + Why + How to fix #[error("Missing API key\n\nRun 'hawkop init' to configure authentication.")]
Respect the User's Environment
use std::io::IsTerminal; // Colors, spinners only when interactive if std::io::stdout().is_terminal() && std::env::var("NO_COLOR").is_err() { // Fancy output OK }
Additional Resources
- Code patterns: patterns.md - Rust/clap templates for common scenarios
- Full checklist: checklist.md - Complete design verification
- 12 Factors explained: 12-factors.md - Deep dive on each principle
- clig.dev reference: clig.md - Local reference for clig.dev guidelines
- Project docs:
- Full referencedocs/CLI_DESIGN_PRINCIPLES.md
HawkOp Conventions
| Convention | Standard |
|---|---|
| Global flags | , , , |
| Pagination | , , |
| Output formats | (default), |
| Navigation hints | on stderr |
| Error prefix | with colored output when TTY |