scaffold-init

name	scaffold-init
description	One-shot rebrand of a freshly-cloned ts-check-scaffold repo into a true empty shell for a new project. Rewrites root package.json (name, version reset to 0.0.0, description), LICENSE (author, year, license id), README.md, deletes any root CHANGELOG.md so the derived project starts with a clean release history, deletes placeholder my-app and tools packages, and scaffolds the user's requested apps and libs as bare shells. The deterministic work happens in scripts/scaffold-init.mjs; this skill just collects inputs, runs the script, and summarizes the result. Use exactly once, right after cloning the scaffold.
argument-hint	--name <project> [--description <text>] [--author <name>] [--license MIT|Apache-2.0|BSD-3-Clause|ISC|UNLICENSED] [--scope @scope] [--apps a,b] [--libs c,d] [--dry-run]
disable-model-invocation	true
allowed-tools	Read, Edit, Write, Glob, Bash(node scripts/scaffold-init.mjs*), Bash(pnpm install*), Bash(pnpm check*), Bash(git status*), Bash(git diff*)

scaffold-init

Rebrands a freshly-cloned ts-check-scaffold repo so it stops being the scaffold and starts being a new project. The deterministic file operations live in scripts/scaffold-init.mjs; this skill handles input collection, invocation, and reporting.

What it changes

• package.json — name, description, and version reset to 0.0.0 so derived projects don't inherit the scaffold's release version
• LICENSE — full text rewritten for the chosen license, with the supplied author + year
• README.md — replaced with a minimal stub (project name + description + pointer to docs/getting-started.md)
• CHANGELOG.md — deleted if present, so the next /version invocation against the renamed project starts a fresh release history (the scaffold's old release notes don't belong to the derived project)
• apps/* and libs/* — the placeholder my-app and tools packages are deleted; new bare-shell packages are created for every name passed via --apps / --libs
• tsconfig.json — root references array rewritten to match the new packages

What stays the same: AGENTS.md, CLAUDE.md, docs/, rules/, scripts/, fallow.toml, cspell.json, .oxlintrc.json, the pnpm check pipeline, and the /version skill. Those are scaffold conventions worth keeping in any derived project.

Arguments

$ARGUMENTS is forwarded verbatim to the script. Supported flags:

• --name <project> (required) — root package name
• --description <text> — root description
• --author <name> — LICENSE copyright holder
• --year <YYYY> — LICENSE year (default: current UTC year)
• --license <id> — MIT | Apache-2.0 | BSD-3-Clause | ISC | UNLICENSED (default: MIT)
• --scope <@scope> — workspace package scope (default: keep what's currently used, falling back to @repo)
• --apps <list> — comma-separated short names for starter apps (default: none)
• --libs <list> — comma-separated short names for starter libs (default: none)
• --keep-placeholders — leave existing apps/* and libs/* in place (rare; useful if you've already started replacing them by hand)
• --dry-run — print the plan, change nothing

When the user invokes you with no arguments

Ask, in one short message, for the values you need before running the script. Required: project name. Recommended: description, author, license, and the initial app/lib names. Then call the script.

Preflight

• Result: !node scripts/scaffold-init.mjs $ARGUMENTS

By the time you read this, one of three things is true on disk:

• mode: "init" with dry_run: false — the changes have already been applied,
• mode: "init" with dry_run: true — nothing changed, the JSON describes what would happen,
• mode: "error" — the script refused to run; nothing changed.

Steps

1. Parse the JSON. Branch on mode:

   • "error" → relay message. Common error_type values: usage (bad/missing args), runtime (unexpected crash). Stop.
   • "init" → continue.

2. Render a summary in this shape (omit empty sections):

   Initialized as: <name>
   License:        <license> · © <year> <author>
   Scope:          <scope>
   
   Removed:
     - CHANGELOG.md
     - apps/my-app
     - libs/tools
   Created:
     - apps/web     (@scope/web)
     - libs/core    (@scope/core)
   Rewrote:
     - package.json (name, version, description)
     - LICENSE
     - README.md
     - tsconfig.json (references)
   

   Use the script's created, removed, and changes arrays. Don't re-read the disk to confirm; the JSON is authoritative.

3. Tell the user what to do next. The script's next_steps array is the canonical answer — render it verbatim:

   Next:
     1. pnpm install
     2. pnpm check
   

4. If the run was a dry run, end by asking whether to re-run for real (same arguments without --dry-run). Do not auto-promote.

Steps — error

• usage → relay the script's message; if --name is missing, ask the user for it and offer to re-invoke.
• runtime → relay the script's message and stop. Don't speculate or retry.

When to use this skill

• Immediately after cloning the scaffold, before any project-specific code lands.
• The user says "rename this scaffold", "rebrand this clone", "init the scaffold", or similar.

When NOT to use this skill

• The repo has already been initialized (root package.json name is no longer ts-check-scaffold and apps/my-app is gone). Renaming an already-initialized project should be a manual edit, not a re-run of this skill — re-running would delete real code in apps/* and libs/*.
• The user wants to add one more package to an existing project. That's mkdir apps/<name> + the per-package shape; see docs/getting-started.md § "Adding a package".

Edge cases

• apps/my-app already deleted, but the user runs the skill again. remove_placeholders is a no-op for non-existent dirs; the rewrite stages still apply. Safe to re-run.
• --apps or --libs overlap. The script rejects with error_type: usage. Tell the user, ask for distinct names.
• The scope flag is @repo (the default) but existing packages use a different scope. The script reads existing packages' scope and prefers that over @repo. To force a switch, pass --scope explicitly.
• Working tree is dirty. The script does not refuse — scaffold-init is meant to be the first thing run after clone, so leftover state is expected. The skill should still mention to the user that git status will show many changes and they should commit or review before continuing.