Back to skills
SkillHub ClubShip Full StackFull Stack

designing-clis

Imported from https://github.com/technicalpickles/pickled-claude-plugins.

Packaged view

This page reorganizes the original catalog entry around fit, installability, and workflow context first. The original raw source lives below.

Stars
7
Hot score
83
Updated
March 20, 2026
Overall rating
C3.1
Composite score
3.1
Best-practice grade
A88.4

Install command

npx @skill-hub/cli install technicalpickles-pickled-claude-plugins-designing-clis

Repository

technicalpickles/pickled-claude-plugins

Skill path: plugins/dev-tools/skills/designing-clis

Imported from https://github.com/technicalpickles/pickled-claude-plugins.

Open repository

Best for

Primary workflow: Ship Full Stack.

Technical facets: Full Stack.

Target audience: everyone.

License: Unknown.

Original source

Catalog source: SkillHub Club.

Repository owner: technicalpickles.

This is still a mirrored public skill entry. Review the repository before installing into production workflows.

What it helps with

  • Install designing-clis into Claude Code, Codex CLI, Gemini CLI, or OpenCode workflows
  • Review https://github.com/technicalpickles/pickled-claude-plugins before adding designing-clis to shared team environments
  • Use designing-clis for development workflows

Works across

Claude CodeCodex CLIGemini CLIOpenCode

Favorites: 0.

Sub-skills: 0.

Aggregator: No.

Original source / Raw SKILL.md

---
name: designing-clis
description: Use when building, improving, or reviewing command-line interfaces for better user experience - before implementing commands/output/errors, when users report confusion or frustration, or when CLI feels hard to use - provides UX principles, visual design techniques, and practical patterns for creating discoverable, delightful CLIs
---

# Designing CLIs

## Overview

Modern CLIs are conversations between human and machine. Great CLIs feel discoverable, responsive, and forgiving. Poor CLIs leave users guessing, waiting, and frustrated.

**Core principle:** Every CLI interaction should answer: "What happened? What can I do? What's next?"

## When to Use

**Building:**
- Creating new CLI commands or tools
- Designing output format, error messages, progress indicators
- Planning CLI architecture (flags, subcommands, interaction model)

**Improving:**
- Enhancing existing CLI user experience
- Adding features to existing commands
- Making CLI "less confusing" or "easier to use"

**Reviewing:**
- Auditing CLI code for UX issues
- Responding to user complaints about difficulty
- Troubleshooting discoverability problems

## Quick Decision Framework

| Working On | Read This |
|------------|-----------|
| New CLI under time pressure | practical-patterns.md (Priority Checklist) |
| Adding to existing CLI | practical-patterns.md (Working with Existing CLIs) |
| Fixing "confusing" CLI | practical-patterns.md (CLI UX Audit Checklist) |
| Command structure, flags | ux-principles.md (Familiarity, Discoverability) |
| Output formatting | visual-techniques.md (Layout, Spacing, Color) |
| Error messages, help text | practical-patterns.md (Error Message Patterns) |
| Overall architecture | ux-principles.md (complete overview) |

## The Six UX Principles

1. **Familiarity** - Use known conventions (--help, --version, verb-noun)
2. **Discoverability** - Guide users (help text, prompts, examples)
3. **Feedback** - Show what's happening (progress, confirmations, state)
4. **Clarity** - Structure output (spacing, alignment, hierarchy)
5. **Flow** - Minimize friction (shortcuts, defaults, scriptability)
6. **Forgiveness** - Handle errors gracefully (clear messages, suggestions, safety)

See ux-principles.md for detailed guidance and examples.

## The Five Visual Techniques

1. **Color** - Semantic meaning (green=success, red=error, yellow=warning)
2. **Spacing** - Visual grouping (blank lines, indentation, alignment)
3. **Layout** - Structured regions (panels, blocks, persistent areas)
4. **Symbols** - Fast signifiers (✓ ✗ ⚠ →, checkboxes, progress indicators)
5. **Structured Feedback** - Narrative output (phases, lists, visible progress)

See visual-techniques.md for implementation patterns.

## Common Mistakes

❌ **Silent operations** - No feedback during slow operations
✅ Show progress, confirmations, or at minimum "Working..."

❌ **Cryptic errors without guidance** - "Error: invalid input"
✅ Explain what's wrong, what's valid, how to fix: "Error: Invalid environment 'production'. Valid: dev, staging, prod"

❌ **No --help text** - Forces users to read docs or source
✅ Every command supports --help with usage and examples

❌ **Wrong exit codes** - Always returns 0, breaks scripting
✅ 0 for success, 1 for errors

❌ **Color-only information** - Inaccessible without color support
✅ Always pair color with text/symbols, support --no-color

❌ **Walls of unstructured text** - Dense output hard to scan
✅ Use spacing, alignment, hierarchy to structure information

## Priority Under Time Pressure

When building CLI urgently, include these first (high impact, low effort):

1. **--help flag** (2 minutes) - Include usage, examples, common flags
2. **Exit codes** (1 minute) - 0=success, 1=error, enables CI/CD
3. **Clear errors** (5 minutes) - What happened + what's valid + how to fix
4. **Progress feedback** (3 minutes) - Show activity during slow operations

Skip initially (lower priority):
- Color schemes (polish, not function)
- Advanced formatting (tables, columns)
- Multiple output formats (JSON, YAML, etc.)

## Cross-References

**Detailed guidance:**
- practical-patterns.md - Checklists, templates, decision trees
- ux-principles.md - Principles with real-world examples
- visual-techniques.md - Implementation patterns for terminal output
- reading-list.md - Sources and deeper learning

**Research materials:**
- research/ - Original blog-style documentation and analysis
designing-clis | SkillHub