cli-scaffold-interpreted

name

cli-scaffold-interpreted

description

This skill should be used when the user asks to "scaffold a CLI in Python", "generate a TypeScript command-line tool", "create a Ruby gem CLI", "make a PHP console app", "build a Perl script with proper argument parsing", or names Python, TypeScript, JavaScript, Ruby, PHP, or Perl as the target language for a new command-line tool — either directly or dispatched from scaffold-cli's language-routing. Generates a freeform, production-grade CLI scaffold for the interpreted paradigm, following cli-architecture's five-pillar doctrine and this skill's own per-language reference idioms — never from stored boilerplate.

Generate a production-grade CLI scaffold for one of the interpreted- paradigm languages — Python, TypeScript/JavaScript, Ruby, PHP, or Perl — freeform, every time, guided by cli-architecture's doctrine and this skill's own per-language reference file. Never copy a stored template; every file this skill produces is written fresh from the pinned idioms below.

Step 1 — Load the doctrine

Invoke cli-architecture via the Skill tool if it has not already been loaded this conversation (e.g. when this skill triggers directly by natural language rather than via scaffold-cli's dispatch, which already loads it). Every pillar in that doctrine applies to every language below — this skill's reference files pin how, not whether.

Step 2 — Resolve the language and load its reference

Requested language	Reference file
Python, py	references/python.md
TypeScript, ts, JavaScript, js	references/typescript-js.md
Ruby, rb	references/ruby.md
PHP	references/php.md
Perl, pl	references/perl.md

Read the resolved reference file in full before generating anything. Each one is structured to map 1:1 onto the five pillars: Framework, Project layout, Help text and completions, NO_COLOR-aware output, Exit codes, --json/--no-input, stdout/stderr discipline, Distribution, Snapshot testing, and a minimal worked example.

Step 3 — Generate the scaffold

Follow the resolved reference's pinned idioms exactly:

• Framework: use the pinned default framework (Typer for Python, oclif for TypeScript/JavaScript, Thor for Ruby, Symfony Console for PHP, Getopt::Long for Perl) — the two exceptions with a documented zero-dependency fallback are Python (argparse) and Ruby (OptionParser): use the fallback only if the user explicitly asks for zero external dependencies, and always label which mode was used, never blend them silently.
• Core/backend separation: generate the importable-core-plus-thin-CLI split exactly as laid out in the reference's Project layout section (src/<pkg>/core.py+cli.py for Python, src/lib/+src/commands/ for TS/JS, lib/<app>/core.rb+exe/<app> for Ruby, src/Core/+ bin/<app> for PHP, lib/<App>/Core.pm+the script entry for Perl) — the core module must be independently importable/requirable with zero CLI-framework code loaded, and must contain no argument-parsing logic.
• Exit codes: apply the frozen 0/1/2 contract from cli-architecture. Every framework in this paradigm needs some explicit handling to fully satisfy the contract — check each reference's own Exit codes section for exactly which part is automatic versus which part must be written by hand; that per-framework detail lives only in the reference, not here, and must not be restated or assumed from memory.
• --json/--no-input, stdout/stderr, NO_COLOR: apply exactly as each reference's corresponding sections specify.
• Distribution: generate the actual packaging metadata as part of the scaffold — pyproject.toml with [project.scripts], the oclif package.json config block, the .gemspec, composer.json plus a Box config, and the Minilla-scaffolded Perl dist files — never leave packaging as a follow-up.
• Snapshot testing: generate the --help-snapshot test using each reference's pinned tool (pytest+syrupy, vitest+@oclif/test, Aruba, PHPUnit+spatie-snapshot-assertions, Test::Script+golden-file) as part of the initial scaffold.

Use each reference's "Minimal worked example" section as a shape guide, not literal text to copy — generated files should match the specific app name and functionality the user described, freeform.

Step 4 — Verify before presenting

Hand the generated scaffold to the cli-scaffold-verifier agent (this plugin's agents/cli-scaffold-verifier.md) for a read-only check against cli-architecture's doctrine and this skill's resolved reference file, before presenting anything to the user. Fix any reported gap and re-verify, except a gap the verifier flags as needs-human-judgment, which should be surfaced to the user directly instead of silently resolved either way.

Present

Report: which language and reference were used, the generated file tree, and the verifier's summary (pass, or what was fixed, or what needs the user's judgment). Note the distribution command the user would run to publish it, and the test command to run the generated --help snapshot test.