Cli Design

Community

notque

cli-design

Design a CLI interface: args, flags, help, output, errors, exit codes, config.

Overview

Publisher	notque
Repository	`vexjoy-agent`
Skill name	`cli-design`
Stars	443
Forks	50
Bundled files	1
License	MIT
Links	Skill source Repository Homepage

Markdown instructions
A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.
Works with any LLM
AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.
1 bundled files
Scripts, templates, and references the model can read while it works. Files are read-only and never executed.
Open source
Published by notque on GitHub. Read the source before you install it.

Installation

Install the Cli Design AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

Open the app and go to Plugins → Skills.
Choose "Install from GitHub".
Paste the skill folder URL below and confirm.
https://github.com/notque/vexjoy-agent/tree/main/skills/engineering/cli-design
Enable the skill in any chat where you want it available.

Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills

git clone --depth 1 https://github.com/notque/vexjoy-agent.git /tmp/vexjoy-agent
mkdir -p .claude/skills
cp -r /tmp/vexjoy-agent/skills/engineering/cli-design .claude/skills/cli-design

Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Cli Design in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Cli Design on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Cli Design is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

Loaded only when it is needed
The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.
Switch models mid-chat
Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

CLI Design

Design a command-line tool's interface before implementation: human-first, script-friendly, Linux-only. Output is a compact spec the user or an agent can implement directly. Rubric source: clig.dev (rebuilt as references/clig-checklist.md).

Deep References

When	Load	Content
Phase 2: applying design rubric	`references/clig-checklist.md`	CLI design checklist condensed from clig.dev

Workflow

Phase 1: SCOPE

Lock the interface with the minimum questions. Proceed with the conventions in Phase 2 when the user is unsure.

Command name and one-sentence purpose.
Primary user: humans, scripts, or both.
Input sources: args vs stdin; files vs URLs. Secrets travel via file or stdin, because flags leak through ps and shell history.
Output contract: human text, --json, --plain, exit codes.
Interactivity: prompts allowed? --no-input needed? confirmation for destructive ops?
Config model: flags, env, config file; precedence.

Gate: name, purpose, and I/O contract are known. Proceed only when gate passes.

Phase 2: DESIGN

Load references/clig-checklist.md and apply it as the default rubric. For each section, pick the convention and record it in the spec. Diverge from a convention only deliberately, and document the divergence in the spec — interfaces are contracts, and surprising contracts break scripts.

Phase 3: DELIVER

Produce the spec from this skeleton. Drop a section only when it genuinely has no content; fill every other section.

Name and one-liner: command name plus a single sentence of purpose
Usage line: the synopsis as --help will print it, global flags and subcommand slot included
Subcommands: purpose of each, whether it mutates state, whether re-running it is safe
Args/flags table: columns for name, type, default, required?, example
I/O contract: primary data and machine-readable output on stdout; everything else (errors, progress, logs) on stderr
Exit codes: map each failure mode to a code — success 0, failure 1, bad usage 2; mint extra codes only for cases scripts must distinguish
Safety: --dry-run, confirmation rules, --force, --no-input
Env/config: env vars; config file path; precedence order with flags highest, then env, project config, user config, system
Examples: enough invocations to cover the common flows; show at least one pipeline or stdin use

Gate: every flag used in the examples appears in the flags table, and every failure mode shown maps to an exit code.

Constraints

Stay at spec altitude: when the request is "design the interface," deliver the spec and stop. Implementation is a separate task.
Keep the spec language-agnostic. Recommend a parsing library only when asked.
Target Linux. Skip Windows/macOS path, signal, and packaging concerns.

Error handling

Request mixes design and implementation

Cause: user says "design and build." Solution: deliver the spec first, get confirmation, then implement against it.

Spec balloons past one page

Cause: subcommand sprawl or speculative flags. Solution: cut flags that lack a named user need; defaults should serve most users without aliases.

Bundled files

The model reads these on demand while the skill is loaded. They are exposed as readable files and are never executed.

references/clig-checklist.md5 KB

Frequently asked questions

What does the Cli Design AI skill do?

Design a CLI interface: args, flags, help, output, errors, exit codes, config.

Why use Cli Design on TypingMind?

Because you install it once and use it with any model. Cli Design is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Cli Design in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/notque/vexjoy-agent/tree/main/skills/engineering/cli-design. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use Cli Design?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Cli Design?

As many as you like. As long as a model supports skills, you can use Cli Design with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Cli Design AI skill free?

Yes. It is published on GitHub by notque under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Content Engine

affaan-m

CommunityPopular

Create platform-native content systems for X, LinkedIn, TikTok, YouTube, newsletters, and repurposed multi-platform campaigns. Use when the user wants social posts, threads, scripts, content…

Crosspost

Multi-platform content distribution across X, LinkedIn, Threads, and Bluesky. Adapts content per platform using content-engine patterns. Never posts identical content cross-platform. Use when the user…

Deep Research

Multi-source deep research using firecrawl and exa MCPs. Searches the web, synthesizes findings, and delivers cited reports with source attribution. Use when the user wants thorough research on any…

Documentation Lookup

Use up-to-date library and framework docs via Context7 MCP instead of training data. Activates for setup questions, API references, code examples, or when the user names a framework (e.g. React,…

Overview

Installation

Install in TypingMind

Install in another agent

Use it in TypingMind

Works with any AI model

Skill instructions

CLI Design

Deep References

Workflow

Phase 1: SCOPE

Phase 2: DESIGN

Phase 3: DELIVER

Constraints

Error handling

Request mixes design and implementation

Spec balloons past one page

Bundled files

Frequently asked questions

Related AI Skills

Set up your own AI workspace now