skills/scaffold-cli/SKILL.md
Scaffolds a production-ready TypeScript CLI and npm package with ESM, a dual tsdown build (CLI binary plus typed library), vitest, oxlint and oxfmt via ultracite, changesets, GitHub Actions CI with OIDC npm publishing, AGENTS.md, and a bundled agent skill definition. Use when creating a new CLI tool, bootstrapping a TypeScript package, scaffolding a node CLI, starting a new npm package, or asking "scaffold a CLI project" or "set up a new TypeScript CLI". For a Next.js web app use scaffold-nextjs; for structuring an existing codebase use define-architecture; for releasing an already-built package use autoship.
npx skillsauth add mblode/agent-skills scaffold-cliInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
references/.scaffold-nextjs), folder structure or module contracts for an existing codebase (use define-architecture), or shipping a release of an existing package (use autoship).Low-freedom scaffold. Generate files exactly as templated, substituting only {{placeholder}} variables. Do not swap tools (no eslint, prettier, tsup, jest, chalk, or ora) or restructure the layout.
| File | Read When |
|------|-----------|
| references/scaffold-configs.md | Step 3: package.json, tsconfig, tsdown, gitignore, license, changeset config, GitHub Actions |
| references/scaffold-source.md | Steps 4-5: src/cli.ts, src/index.ts, src/types.ts, AGENTS.md, README.md, skills/SKILL.md |
| references/agent-friendly-cli.md | Step 4: agent-friendly CLI patterns (input validation, dry-run, confirmation, schema) |
| references/post-scaffold.md | Steps 6-7: post-scaffold commands, validation checklist, troubleshooting |
Copy this checklist to track progress:
Scaffold progress:
- [ ] Step 1: Gather project info
- [ ] Step 2: Create directory structure
- [ ] Step 3: Generate config files
- [ ] Step 4: Generate source files
- [ ] Step 5: Generate docs and skill
- [ ] Step 6: Run post-scaffold commands
- [ ] Step 7: Validate scaffold
Ask only for what the user didn't provide:
| Variable | Example | Default | Used in |
|----------|---------|---------|---------|
| {{name}} | md-tools | required | package.json name, README title |
| {{description}} | CLI tool to convert content to markdown | required | package.json, README, SKILL.md |
| {{bin}} | md | same as {{name}} | package.json bin field, CLI examples |
| {{repo}} | acme/md-tools | required | package.json repository, badges |
| {{author}} | Your Name | required | package.json, LICENSE |
| {{year}} | 2026 | current year | LICENSE |
{{name}}/
.changeset/
.github/
workflows/
src/
skills/{{bin}}/
Load references/scaffold-configs.md. Generate all config files, replacing every {{placeholder}}.
Files: package.json, tsconfig.json, tsdown.config.ts, .gitignore, LICENSE.md, .changeset/config.json, .changeset/README.md, .github/workflows/ci.yml, .github/workflows/npm-publish.yml
Load references/scaffold-source.md. Generate:
src/cli.ts: Commander entry point with agent-friendly defaults (--output text|json, --no-input, stdout data / stderr log split, JSON error envelope)src/index.ts: Public API exportssrc/types.ts: Shared type definitionsWhen a command takes an identifier, path, or URL, or mutates state, also load references/agent-friendly-cli.md and copy the matching pinned pattern (input validation, dry-run, confirmation, or the schema command).
From the same references/scaffold-source.md, generate:
AGENTS.md: commands, architecture, gotchasREADME.md: install, usage, API, agent skill install, licenseskills/{{bin}}/SKILL.md: agent skill definitionDo not create the CLAUDE.md symlink here; Step 6 creates it exactly once.
Load references/post-scaffold.md. Run the full sequence in the order given there.
Run the validation checklist in references/post-scaffold.md. Every item must pass with command output as evidence, not a visual once-over. Includes the placeholder sweep (grep for leftover {{variable}} tokens).
Runtime: @clack/prompts, commander
Development (in the package.json template): @changesets/cli, @types/node, tsdown, typescript, ultracite, vitest
Added by ultracite init (never list by hand): oxlint, oxfmt, lefthook, plus check, fix, and prepare scripts
Replacements: node:util styleText instead of chalk (stable since Node 22.13), @clack/prompts spinner instead of ora.
"type": "module"); a require() or missing .js import extension fails the NodeNext typecheck and build.src/cli.ts. tsdown's banner injects #!/usr/bin/env node at build; a source shebang doubles it in dist/cli.js.oxlint/oxfmt scripts or devDeps by hand, or call those binaries directly. ultracite init owns them; run npm run check (lint) and npm run fix (autofix). By-hand entries cause duplicate scripts and version skew.ultracite init before git init. Its lefthook integration installs hooks into .git/hooks and fails without a repo."test": "vitest run" without --passWithNoTests. Zero test files means plain vitest run exits 1 and the first CI run goes red.console.log breaks an agent parsing --output json.--no-input; a prompt under a pipe hangs forever.For releases of the generated package, the autoship skill drives the changeset, CI, and Version Packages PR flow.
development
Fans out four concurrent review agents over the current diff, then APPLIES fixes directly to the working tree and verifies the build. Mutates code; it does not produce a report. Covers reuse (duplicate logic, hand-rolled stdlib, reinvented platform features), quality (hacky patterns, React/TypeScript hygiene, over-memoisation, exhaustive-deps, `any`, dead code, `CLAUDE.md`/`AGENTS.md` violations), efficiency (unnecessary work, missed concurrency, hot-path bloat), and test discipline (bug fixes without a repro test, useless tests to delete, missing tests only when they prevent a named failure). Use when the user says "tidy this up", "simplify", "clean up this diff", "polish my changes", "check for duplication", or "any reuse opportunities?", i.e. when the intent is to have the changes made automatically. For a read-only report that lists findings without touching files, use `pr-reviewer` instead. This skill edits code; for the PR's title, description, or commit history, use `pr-creator`.
development
Decides what an interface should do before UI is built or audited: interaction choice, action scope and consequence, reachable states, resilience, and accessibility as task completion. Works from a brief, spec, mockup, intent, or existing UI. Use when asked "is this the right interaction", "design the flow", "what control should this use", "what should this action affect", "which states should this have", "make this resilient", or "what breaks here". For building or styling use ui-design; for built-code audits use ui-audit; for copy wording use copywriting.
development
Builds and stress-tests implementation plans in two modes. Create mode scans code and docs, asks one question at a time with a recommended answer, runs a blindspot pass when the user is new to the area, then writes a plan file. Review mode scores completeness, feasibility, scope, testability, risk, and assumptions, verifies checkable claims, and writes resolutions back until every dimension reaches 5/5. Use when asked to "create a plan", "plan this feature", "I want to build X", "grill me", "think this through", "blindspot pass", "unknown unknowns", "this is new to me", "review my plan", "rubber duck this", "stress test this plan", "is this plan ready", "get this plan to 5/5", "what am I missing", "verify this claim", "prove this plan", "fact-check this plan", or when the user explicitly wants a plan artifact before implementation. For code review use pr-reviewer; for architecture briefs use define-architecture.
tools
Audits the smallest relevant developer-facing surface of a library, CLI, SDK, or npm package across API contracts, errors, CLI behavior, public types, onboarding, and config. Uses candidate-first rule loading, bounded local evidence, and compact root-cause findings. Use when asked to "audit my CLI", "make this CLI agent-friendly", "is this API ergonomic", "review the developer experience", "improve these errors", "simplify first run", or "review my SDK". For end-user UI use ui-audit, for agentic-app trust use ax-audit, for docs prose use docs-writing, for README work use readme-creator, and for repo architecture use define-architecture. Inside a product that also ships a UI, this is the skill for the developer-facing half, so pick it when the complaint is about an import, command, error string, exported type, or config rather than a screen.