{"slug":"meta-planning-cli-planning","title":"meta-planning-cli-planning","summary":"CLI specification planning frameworks. Use when a spec touches a command surface, an interactive flow, config precedence, exit codes, or output modes. Covers flag contracts, prompt flow design, precedence tables, exit-code taxonomy, TTY/piped/JSON output, error text, signals, and","platform":"Claude","tags":[],"authorName":"LLM Mart","authorSlug":"llm-mart","score":0,"source":"github","price":null,"verified":false,"createdAt":"2026-09-29T15:28:10.858957Z","repo":{"url":"https://github.com/agents-inc/skills","stars":24,"forks":8,"license":"MIT","updatedAt":"2026-09-07T17:50:55Z"},"bodyHtml":"<hr>\n<h2>name: meta-planning-cli-planning\ndescription: CLI specification planning frameworks. Use when a spec touches a command surface, an interactive flow, config precedence, exit codes, or output modes. Covers flag contracts, prompt flow design, precedence tables, exit-code taxonomy, TTY/piped/JSON output, error text, signals, and cross-platform concerns.</h2>\n<h1>CLI Planning Frameworks</h1>\n<blockquote>\n<p><strong>Quick Guide:</strong> Specify each contract the feature actually touches — the full flag table for a new surface, the per-step prompt table for an interactive flow, a precedence table per config key, an exit code for every terminating path, and output behaviour per context (TTY, piped, <code>--json</code>, quiet, verbose). Apply a framework only when the spec touches its artifact class; a config-only change needs no prompt-flow section.</p>\n</blockquote>\n<hr>\n<p>&lt;critical_requirements&gt;</p>\n<h2>CRITICAL: Before Specifying CLI Contracts</h2>\n<blockquote>\n<p><strong>All specifications must be grounded in the codebase's real commands, prompts, resolvers, and constants</strong> — reference specific files with line numbers</p>\n</blockquote>\n<p><strong>(You MUST give every prompted value a non-interactive twin — a flag or config key — and state what happens with no TTY and no flag)</strong></p>\n<p><strong>(You MUST give every terminating path an exit code named as a constant, with cancellation distinct from failure)</strong></p>\n<p><strong>(You MUST specify output per context — TTY, piped, <code>--json</code>, quiet, verbose — and state which stream carries payload versus diagnostics)</strong></p>\n<p><strong>(You MUST state config precedence per key as a table with merge semantics — \"merged\" without a rule is not a rule)</strong></p>\n<p><strong>(You MUST apply each framework only when the spec touches its artifact class — an unused section is omitted, never filled with placeholders)</strong></p>\n<p>&lt;/critical_requirements&gt;</p>\n<hr>\n<p><strong>Auto-detection:</strong> CLI spec, command surface design, flag contract, subcommand, interactive wizard spec, prompt flow, config precedence, exit codes, JSON output mode, help text spec, signal handling spec</p>\n<p><strong>When to use:</strong></p>\n<ul>\n<li>Specifying a new command or subcommand surface (arguments, flags, aliases)</li>\n<li>Specifying an interactive flow (prompt sequence, keybindings, cancellation)</li>\n<li>Specifying configuration keys and their resolution order</li>\n<li>Specifying output contracts (TTY, piped, <code>--json</code>, quiet, verbose)</li>\n<li>Specifying exit codes, error messages, help text, or signal handling</li>\n<li>Changing an existing surface (backward compatibility, deprecation path)</li>\n</ul>\n<p><strong>When NOT to use:</strong></p>\n<ul>\n<li>When implementing CLI code (use the relevant CLI implementation skill)</li>\n<li>For backend API or frontend UI specifications (use the api/web planning skills)</li>\n<li>For the planning PROCESS itself — research, scope fencing, success criteria — which the PM agent carries</li>\n</ul>\n<p><strong>Key patterns covered:</strong></p>\n<ul>\n<li>Command surface design (argument vs flag vs subcommand vs prompt)</li>\n<li>Per-flag contract fields and naming rules</li>\n<li>Interactive flow design (when to prompt, per-step specification)</li>\n<li>Configuration precedence tables and merge semantics</li>\n<li>Exit-code contract rules</li>\n<li>Output contract per context, stream split, <code>--json</code> shape</li>\n<li>Error-message anatomy and help-text requirements</li>\n<li>Signal handling and cancellation invariants</li>\n<li>Cross-platform concerns</li>\n<li>Common CLI spec failures</li>\n</ul>\n<p><strong>Detailed Resources:</strong></p>\n<ul>\n<li><a href=\"examples/core.md\">examples/core.md</a> - Per-artifact spec section templates and a worked example specification</li>\n</ul>\n<hr>\n\n<hr>\n\n<hr>\n<p>&lt;decision_framework&gt;</p>\n<h2>Decision Framework</h2>\n<h3>Which Spec Sections Does This Feature Need?</h3>\n<p>Apply a framework only when the spec touches its artifact class. The per-artifact section templates live in <a href=\"examples/core.md\">examples/core.md</a>.</p>\n<pre><code>Does the spec add or change a command, argument, or flag?\n├─ YES → Command Surface section (Pattern 1) + Exit Codes (Pattern 4) + Output Contract (Pattern 5)\n└─ Does it add or change prompts or a wizard step?\n    ├─ YES → Interactive Flow section (Pattern 2), each prompt with its flag twin\n    └─ Does it add or change config keys?\n        ├─ YES → Configuration Resolution section (Pattern 3), one table per key\n        └─ Does it only change messages, help, or diagnostics?\n            ├─ YES → Error Messages / Help Text section (Pattern 6) with verbatim text\n            └─ NO  → None of these frameworks applies; do not force one in\n</code></pre>\n<p>Always applicable when the command runs long or writes: Signal Handling (Pattern 7). Always worth a pass when files or paths are involved: Cross-Platform (Pattern 8).</p>\n<h3>Common Spec Failures</h3>\n<table>\n<thead>\n<tr>\n<th>Failure</th>\n<th>Consequence</th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td>Prompt with no flag twin</td>\n<td>Command is unusable in CI; discovered only after release</td>\n</tr>\n<tr>\n<td>Undefined exit code for a path</td>\n<td>The developer invents one; scripts branch on a number nobody documented</td>\n</tr>\n<tr>\n<td>Output specified for TTY only</td>\n<td>Piped output carries ANSI escapes and spinner frames into the consumer</td>\n</tr>\n<tr>\n<td>Config precedence left as \"merged\"</td>\n<td>Arrays merge in one place and replace in another</td>\n</tr>\n<tr>\n<td>Paraphrased error text</td>\n<td>Every command words the same failure differently</td>\n</tr>\n<tr>\n<td>No cancellation requirement</td>\n<td>Ctrl+C leaves half-written files and a hidden cursor</td>\n</tr>\n<tr>\n<td>Flag renamed without a plan</td>\n<td>Existing scripts break silently</td>\n</tr>\n<tr>\n<td>\"Follows existing patterns\"</td>\n<td>No file reference means no pattern was verified to exist</td>\n</tr>\n</tbody>\n</table>\n<p>&lt;/decision_framework&gt;</p>\n<hr>\n<p>&lt;red_flags&gt;</p>\n<h2>RED FLAGS</h2>\n<p><strong>High Priority Issues (a spec with one of these is incomplete):</strong></p>\n<ul>\n<li>A prompted value with no flag or config twin</li>\n<li>A terminating path with no exit code, or a magic number instead of a constant</li>\n<li>Output described only for the TTY case</li>\n<li>A config key whose merge semantics are \"merged\"</li>\n<li>Error or prompt text described rather than written verbatim</li>\n<li>A long-running or writing command with no cancellation invariant</li>\n</ul>\n<p><strong>Medium Priority Issues:</strong></p>\n<ul>\n<li>A new exit code where an existing failure class fits</li>\n<li>A new subcommand where a flag on an existing command would do</li>\n<li>A renamed or removed flag with no deprecation path</li>\n<li>Help text without worked examples</li>\n<li>A <code>--json</code> mode with no error shape</li>\n</ul>\n<p><strong>Common Mistakes:</strong></p>\n<ul>\n<li>Designing flags without reading sibling commands (short-form collisions)</li>\n<li>Treating cancellation as an error instead of its own exit class</li>\n<li>Specifying spinner text but not the piped-output equivalent</li>\n<li>Leaving \"nothing to do\" output unspecified on idempotent re-runs</li>\n</ul>\n<p><strong>Gotchas &amp; Edge Cases:</strong></p>\n<ul>\n<li>An accelerator key that is live while a text input has focus swallows typed characters</li>\n<li><code>--dry-run</code> must share the real run's failure codes or CI cannot trust it</li>\n<li>An explicitly empty value (<code>--tag \"\"</code>) and an absent one are different inputs; decide which wins</li>\n<li>Second Ctrl+C during cleanup needs its own answer</li>\n</ul>\n<p>&lt;/red_flags&gt;</p>\n<hr>\n<p>&lt;critical_reminders&gt;</p>\n<h2>CRITICAL REMINDERS</h2>\n<blockquote>\n<p><strong>All specifications must be grounded in the codebase's real commands, prompts, resolvers, and constants</strong></p>\n</blockquote>\n<p><strong>(You MUST give every prompted value a non-interactive twin — a flag or config key — and state what happens with no TTY and no flag)</strong></p>\n<p><strong>(You MUST give every terminating path an exit code named as a constant, with cancellation distinct from failure)</strong></p>\n<p><strong>(You MUST specify output per context — TTY, piped, <code>--json</code>, quiet, verbose — and state which stream carries payload versus diagnostics)</strong></p>\n<p><strong>(You MUST state config precedence per key as a table with merge semantics)</strong></p>\n<p><strong>(You MUST apply each framework only when the spec touches its artifact class — an unused section is omitted, never filled)</strong></p>\n<p><strong>Failure to specify these contracts produces CLIs whose developers invent flags, guess exit codes, break piped and CI callers, and leave half-written files behind on Ctrl+C.</strong></p>\n<p>&lt;/critical_reminders&gt;</p>\n","files":[{"path":"examples/core.md","sizeBytes":19987,"isText":true},{"path":"SKILL.md","sizeBytes":23958,"isText":true}],"reviewScore":null,"reviewSummary":null,"trust":{"provenance":"trusted-source-unreviewed","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow.","bodySource":null},"bodyLocked":false,"purchaseUrl":null,"sourceUrl":null,"report":{"provenance":"trusted-source-unreviewed","screen":{"ran":true,"outcome":"clean","suspicious":0,"notes":0,"hiddenCharacters":false},"virusScan":{"engine":"clamav","status":"clean","scannedAt":"2026-09-29T15:30:42.49315Z","sha256":"A7433D3D5E0D165E953E5BAE412A6D9B1B6AA284D9DD24981933DC9903FE8A68","sizeBytes":14902},"review":null,"source":{"repositoryUrl":"https://github.com/agents-inc/skills","path":"dist/plugins/meta-planning-cli-planning/skills/meta-planning-cli-planning","license":"MIT","commit":"3a51ef571e996b18294bf776d53dbdad26de0617","subtreeSha":"AFBAF81A542C7323FD3F89C7156B57D270F5515637FA86370474A2B250C19354","lastSyncedAt":"2026-09-29T15:27:48.914434Z"},"reviewedAt":"2026-09-29T15:36:06.881361Z","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow."},"install":[{"target":"skills-cli","command":"npx skills add https://github.com/agents-inc/skills/tree/main/dist/plugins/meta-planning-cli-planning/skills/meta-planning-cli-planning"},{"target":"claude-code","command":"claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install agents-inc-skills@llmmart"},{"target":"git","command":"git clone https://github.com/agents-inc/skills.git"}]}