Build production-quality CLIs with language detection and a five-step approval-gated workflow. Use when wrapping an existing module or app. Don't use for GUI/TUI apps, web APIs, or one-off shell scripts.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Build production-quality CLI tools for any module or application, in any language.
Reference files (read each one on demand, not upfront, to keep the agent's context budget small):
references/cli-libraries.md — read during Step 2 (Design) to recommend libraries and during Step 4 (Execute) for starter scaffoldsreferences/btop-style.md — read during Step 2 (Design) to write the Visual style section and during Step 4 (Execute) to build the style module and its testsreferences/testing-patterns.md — read during Step 4 (Execute) when writing testsreferences/final-report.md — read during Step 5 (Summarize) to write the final reportRun this section once, before Step 1, so the analysis reads the current code. If git rev-parse --git-dir fails, the directory is not a git repository: skip this section, the Branch-First Safety Rule, and the Step 4 commits, and list no git repository: no branch or commits under Uncertainty: in the final report.
In a git repository, sync the current branch with remote:
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$branch"
If the working tree is not clean, stash first, sync, then restore:
git stash push -u -m "pre-sync"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin && git pull --rebase origin "$branch"
git stash pop
If origin is missing, pull is unavailable, or rebase/stash conflicts occur, stop and ask the user before continuing.
Run this rule at the start of Step 4, before the first file write, with CLI_NAME set to the tool name approved in Step 2. Only create a new branch if on main or master — otherwise continue on the existing branch (the user likely set it up already or is resuming work):
current_branch="$(git rev-parse --abbrev-ref HEAD)"
if [ "$current_branch" = "main" ] || [ "$current_branch" = "master" ]; then
slug="$(echo "${CLI_NAME:-cli}" | tr '[:upper:] ' '[:lower:]-' | tr -cd 'a-z0-9-')"
ts="$(date +%Y%m%d-%H%M%S)"
git checkout -b "feat/cli-${slug}-${ts}"
fi
Explicit approval is a user reply that accepts the presented item as it stands, such as "approved" or "looks good, go ahead". A question, a change request, or no reply is not approval. Steps 1-3 write no files.
Understand the project before proposing anything.
Auto-detect language by checking for manifest files:
package.json / tsconfig.json -> JavaScript/TypeScriptpyproject.toml / setup.py / setup.cfg / requirements.txt -> Pythongo.mod -> GoCargo.toml -> Rustpom.xml / build.gradle / build.gradle.kts -> Java/KotlinGemfile / *.gemspec -> RubyIdentify existing CLI/entry points: check for bin fields, __main__.py, main.go, fn main(), existing arg parsing code, or scripts in package.json.
Record the module structure: list the public functions or classes the CLI will expose, their inputs and outputs, the core data types, and runtime dependencies.
Ask clarifying questions (only what cannot be inferred):
Present the findings: detected language, entry points, the list of exposed functions, and the open questions. Wait for explicit approval before Step 2.
Present a structured CLI design document:
references/btop-style.md: components per command, theme roles, fallbacks, the styling library or zero-dependency module, and a mockup of one command's styled output. Use another style only when the user explicitly declines this one.Approval loop:
No implementation before design approval. If the user ends the run without approving the design, stop; the final status is BLOCKED.
Break implementation into three phases, each with granular tasks.
Phase 1 — Foundation (get a working CLI skeleton):
Phase 2 — Complete (full feature set):
Phase 3 — Polish (optional; include it only when the user confirms it):
Each task includes:
Use the same approval loop as Step 2 for the plan.
No execution before plan approval. If the user ends the run without approving the plan, stop; the final status is BLOCKED.
Before the first file write, apply the Branch-First Safety Rule. Then, for each task in the approved plan:
pytest, npm test, go test ./..., cargo test).not run.At the end of each phase:
--help plus at least one approved example invocation) and show the output. From Phase 2 on, also run one example with FORCE_COLOR=1, unless the user declined the btop style (references/btop-style.md → Verify). A demo that exits non-zero is a failing test (item 3).If a task needs a change to the approved design (a command, option, or output format differs), stop Step 4. Present the proposed change and wait for explicit approval before you continue.
Print the final report once, after the last Step Completion Report, as plain text in the chat. Do not write a report file unless the user asks for one. Read references/final-report.md for each part's contents, the status rules, and two examples. The four parts, in this order:
Result: — the status first (COMPLETE, PARTIAL — <reason>, or BLOCKED — <reason>), then the tool name.Evidence: — only checks that ran: files, test counts, demo exit codes.Uncertainty: — untested behavior and assumptions, labeled apart from verified facts.Decision: — the approval needed, or No approval needed., then each remaining user action.After the four parts, print the usage quick-start (install command and 3-5 example invocations) and the next steps (suggested improvements, missing features, distribution TODO).
Status rules — apply the first rule that matches:
BLOCKED — the run stopped before the first file write, for example because the design or plan was not approved, there was no module to wrap and the user gave no answer, or Repo Sync hit a conflict or a missing origin the user did not approve working around.PARTIAL — at least one file was written, and then any of these happened: a test or demo still fails, a test command could not run, the user stopped Step 4 early, an approved task is not done, or a design change awaits approval.COMPLETE — every task in the approved plan is done, and every test command and demo ran and passed. A Phase 3 the user declined does not make the run partial.After running this skill on a Python module called mylib, the final report looks like this (full example: references/final-report.md):
Result: COMPLETE — mylib CLI (Python, click) with subcommands run and info
Evidence:
Branch: feat/cli-mylib-20260419-143200
Created: cli/main.py, cli/commands/run.py, cli/commands/info.py, tests/test_cli.py
Modified: pyproject.toml ([project.scripts] entry point)
pytest: 8 passed, 0 failed
Visual style: btop, rich
Demo: mylib --help, mylib --version, mylib info, env -u NO_COLOR FORCE_COLOR=1 mylib info (all exit 0)
Uncertainty:
Tested on macOS only. Styled output not viewed in a real terminal; light-background terminal not tried.
Shell completions not built (Phase 3 declined).
Decision: No approval needed.
Remaining action: review the branch and push it.
Usage quick-start:
pip install -e .
mylib --help
mylib run --input data.csv --output results.json
mylib info --format json
Step Completion Report (Steps 4-5):
◆ Execute + Summarize (step 4-5 of 5 — mylib CLI)
··································································
Implementation: √ pass (2 subcommands, 4 files created)
Test coverage: √ pass (8/8 tests passing)
Phase demos completed: √ pass (help, version, run verified)
Final report delivered: √ pass
Criteria: √ 4/4 met
____________________________
Result: PASS
references/btop-style.md).--help works at every command level and --version is implementedreferences/testing-patterns.mdNO_COLOR env var or --no-color flag is respected--format json, piped, and NO_COLOR output contain no ESC (0x1b) byteResult: and a status chosen by the Step 5 status rules, then Evidence:, Uncertainty:, and Decision:references/final-report.md). Human understanding stays unconfirmed until a user answers those checksAfter completing each major step, output a status report in this format:
◆ [Step Name] ([step N of M] — [context])
··································································
[Check 1]: √ pass
[Check 2]: √ pass (note if relevant)
[Check 3]: × fail — [reason]
[Check 4]: √ pass
[Criteria]: √ N/M met
____________________________
Result: PASS | FAIL | PARTIAL
Adapt the check names to match what the step actually validates. Use √ for pass, × for fail, and — to add brief context. The "Criteria" line summarizes how many acceptance criteria were met. The "Result" line gives the overall verdict.
Phase: Analyze (Step 1) — checks: Project analysis, Language detected, Entry points identified, Clarifying questions asked
Phase: Design (Step 2) — checks: Design approval, Command tree defined, I/O behavior specified, Example invocations provided, Visual style defined
Phase: Plan (Step 3) — checks: Plan approval, Phases broken down, Tasks have goals and tests, Effort estimated
Phase: Execute + Summarize (Steps 4–5) — checks: Implementation, Test coverage, Phase demos completed, Final report delivered
| Situation | Action |
|---|---|
| No clear module to wrap | Ask user what functionality the CLI should expose |
| Multiple languages detected | Ask user which language to use, recommend the one with more CLI code |
| Existing CLI found | Offer to extend/refactor rather than rebuild; audit existing CLI first |
| Unknown framework requested | Read the framework's official documentation; if none is reachable, ask the user for a docs link |
| Tests fail after implementation | Fix and re-run; never skip broken tests. After 3 failed attempts on one task, stop and ask the user (Step 4) |
| Test command cannot run | Tell the user; continue only after explicit approval, and record the tests as not run (status PARTIAL) |
| Not a git repository | Skip Repo Sync, the branch rule, and commits; list it under Uncertainty: |
Every CLI built with this skill must include:
--help works at every level)references/testing-patterns.md (0 = success, non-zero = failure)--long-flag, -s short flag, -- to end optionsNO_COLOR env var or --no-color flag--version prints version and exitsまだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Create, update, or audit AGENTS.md (default) or CLAUDE.md agent instructions: set up, prune, add a rule, or merge CLAUDE.md or .cursorrules into one file Claude Code, Codex, and Cursor all read. Don't use for READMEs, skills, or subagents.
日本語の概要は準備中です。原文の説明を表示しています。
Find open AI engineering jobs that fit a candidate, verify location and apply links, and assess each employer's product. Use for one-off shortlists or a job alert's research step. Don't use for résumé writing, job applications, or company news.
日本語の概要は準備中です。原文の説明を表示しています。
Generate App Store screenshots and header/search images for iPhone, iPad and Mac from a codebase or landing page, or re-render a set. Use when preparing a submission. Don't use for ASO keywords, review audits, icons, videos, or Google Play.
日本語の概要は準備中です。原文の説明を表示しています。
Audit iOS/macOS apps against App Store Review Guidelines before submission, with evidence-backed verdicts and fixes. Don't use for Google Play, general code review, or rejection appeals.
日本語の概要は準備中です。原文の説明を表示しています。
Optimize App Store and Google Play listings via a 7-phase, plan-approval-gated ASO workflow (keyword strategy, metadata, localization). Don't use for web SEO, paid UA campaigns, or pre-submission compliance audits.
日本語の概要は準備中です。原文の説明を表示しています。
Generate a commit message, stage all changes, and push to remote after scanning for secrets, large files, and protected-branch risks. Skip for opening PRs, code review, or cutting releases/tags.
日本語の概要は準備中です。原文の説明を表示しています。