
Cli Developer
Structure command trees, flags, and layered config when you or your agent scaffold a production-ready CLI.
Overview
CLI Developer is an agent skill most often used in Build (also Ship) that teaches command hierarchy, flag conventions, and six-layer configuration resolution for terminal tools.
Install
npx skills add https://github.com/jeffallan/claude-skills --skill cli-developerWhat is this skill?
- Documents nested command hierarchies with positional args, boolean flags, and short/long option pairs
- Defines a 6-layer configuration precedence stack from CLI flags down to hard-coded defaults
- Covers variadic arguments and repeatable exclude-style flags for batch operations
- Shows JavaScript-style config merge order for implementing resolution in real CLIs
- Aligns deploy-style subcommands with --dry-run, --force, and --config patterns
- 6-layer configuration priority stack
- 4 illustrated config file locations plus defaults
Adoption & trust: 2.8k installs on skills.sh; 9.7k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are building a CLI with an agent but lack a shared pattern for commands, flags, and where settings should live.
Who is it for?
Indie builders or small teams defining UX for a new Rust, Node, or Python CLI before implementation.
Skip if: Teams that only need one-off shell scripts with no subcommands, persistent config, or documented flag surface.
When should I use this skill?
You are designing or refactoring a CLI’s commands, flags, or config resolution with an agent.
What do I get? / Deliverables
You get a consistent command tree, flag vocabulary, and config precedence model ready to implement in your chosen CLI framework.
- Command hierarchy sketch
- Flag and option naming scheme
- Config merge precedence specification
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
CLI products are designed and implemented in Build; this skill is the canonical shelf for that work even when deploy-style subcommands touch Ship later. Agent-tooling fits skills that shape how developers and coding agents invoke tools from the terminal with consistent UX.
Where it fits
Map init, config, deploy, and plugins subcommands before your agent writes the parser.
Standardize --config and environment overrides for a tool that talks to external APIs.
Add deploy --dry-run and --force flags that match conventions users already know.
Generate help text and README examples that mirror the documented command tree.
How it compares
Use as design reference for argv UX rather than ad-hoc prompt guesses or copying a full CLI framework’s docs wholesale.
Common Questions / FAQ
Who is cli-developer for?
Solo and indie developers using Claude Code, Cursor, or Codex who want agent help to design CLIs that feel familiar to power users.
When should I use cli-developer?
During Build when scaffolding a new CLI or refactoring commands; in Ship when adding deploy or dry-run flags; anytime you need env-plus-file config layering.
Is cli-developer safe to install?
It is procedural documentation only—review the Security Audits panel on this Prism page before trusting any third-party skill package in your repo.
SKILL.md
READMESKILL.md - Cli Developer
# CLI Design Patterns ## Command Hierarchy ``` mycli # Root command ├── init [options] # Simple command ├── config │ ├── get <key> # Nested subcommand │ ├── set <key> <value> │ └── list ├── deploy [environment] # Command with args │ ├── --dry-run # Flag │ ├── --force │ └── --config <file> # Option with value └── plugins ├── install <name> ├── list └── remove <name> ``` ## Flag Conventions ```bash # Boolean flags (presence = true) mycli deploy --force --dry-run # Short + long forms mycli -v --verbose mycli -c config.yml --config config.yml # Required vs optional mycli deploy <env> # Positional (required) mycli deploy --env production # Flag (optional) # Multiple values mycli install pkg1 pkg2 pkg3 # Variadic args mycli --exclude node_modules --exclude .git ``` ## Configuration Layers Priority order (highest to lowest): 1. **Command-line flags** - Explicit user intent 2. **Environment variables** - Runtime context 3. **Config files (project)** - `.myclirc`, `mycli.config.js` 4. **Config files (user)** - `~/.myclirc`, `~/.config/mycli/config.yml` 5. **Config files (system)** - `/etc/mycli/config.yml` 6. **Defaults** - Hard-coded sensible defaults ```javascript // Example config resolution const config = { ...systemDefaults, ...loadSystemConfig(), ...loadUserConfig(), ...loadProjectConfig(), ...loadEnvVars(), ...parseCliFlags(), }; ``` ## Exit Codes Standard POSIX exit codes: ```javascript const EXIT_CODES = { SUCCESS: 0, GENERAL_ERROR: 1, MISUSE: 2, // Invalid arguments PERMISSION_DENIED: 77, NOT_FOUND: 127, SIGINT: 130, // Ctrl+C }; ``` ## Plugin Architecture ``` mycli/ ├── core/ # Core functionality ├── plugins/ │ ├── aws/ # Plugin: AWS integration │ │ ├── package.json │ │ └── index.js │ └── github/ # Plugin: GitHub integration │ ├── package.json │ └── index.js └── plugin-loader.js # Discovery & loading ``` Plugin discovery: 1. Check `~/.mycli/plugins/` 2. Check `node_modules/mycli-plugin-*` 3. Check `MYCLI_PLUGIN_PATH` env var ## Error Handling Patterns ```javascript // Good: Actionable error messages Error: Config file not found at /path/to/config.yml Tried locations: • ./mycli.config.yml • ~/.myclirc • /etc/mycli/config.yml Run 'mycli init' to create a config file, or use --config to specify location. // Bad: Unhelpful errors Error: ENOENT ``` ## Interactive vs Non-Interactive ```javascript // Detect if running in CI/CD const isCI = process.env.CI === 'true' || !process.stdout.isTTY; if (isCI) { // Non-interactive: fail fast with clear errors if (!options.environment) { throw new Error('--environment required in non-interactive mode'); } } else { // Interactive: prompt user const environment = await prompt({ type: 'select', message: 'Select environment:', choices: ['development', 'staging', 'production'], }); } ``` ## State Management ``` ~/.mycli/ ├── config.yml # User configuration ├── cache/ # Cached data │ ├── plugins.json │ └── api-responses/ ├── credentials.json # Sensitive data (600 perms) └── state.json # Session state ``` ## Performance Patterns ```javascript // Lazy loading: Don't load unused dependencies if (command === 'deploy') { const deploy = require('./commands/deploy'); // Load on demand await deploy.run(); } // Caching: Avoid repeated API calls const cache = new Cache('~/.mycli/cache', { ttl: 3600 }); let plugins = await cache.get('plugins'); if (!plugins) { plugins = await fetchPlugins(); await cache.set('plugins', plugins); } // Async operations: Don't block unnecessarily await Promise.all([ validateConfig(), checkForUpdates(), loadPlugins(), ]); ``` ## Versioning & Updates ```javascript // Check for updates (non-blocking) checkForUpdat