claude-vibe-squad: Skill for Claude Code

Auto-Scaffold

Generate the standard repository files at delivery so a project arrives usable rather than as a bare tree of source. This runs during Phase 6 “Local deliver” of the S0–S7 project lifecycle, after verification and before local handoff. The reciprocal missing-standard-files trigger lives in shared/modes/project.md; that mode contract decides when this skill is loaded.

This skill writes files. That makes it a gated action, and the gate is not a formality — see Approval below.

The overwrite rule

Never overwrite a file that already exists. Skip it, and report the skip.

This is the rule that matters most, because every file this skill generates is a file a human is likely to have written by hand and cared about. A generated README replacing a hand-written one destroys work that generally is not recoverable from the branch, and the loss is silent — a scaffold step that reports success while having replaced the project's documentation. Detect by checking each target before writing. Overwriting requires explicit operator instruction naming the specific file.

What gets generated

• README.md — title, one-line description, what it does, how to run it, and the tech stack. Derive from the project scope and from what the repo actually contains, not from what the plan intended.
• CHANGELOG.md — derived from the commit history of the work. Group by change type. Where there is no meaningful history, write a minimal initial entry rather than fabricating a release narrative.
• LICENSE — only with an operator-confirmed choice. See Approval.
• CLAUDE.md — the agent-context file, so a future session in that repo starts oriented: what the project is, its conventions, how to build and test it, and the constraints that are not visible in the code. Note that CLAUDE.md is this repo's convention; the source pattern's companion context files have no counterpart here and are not created.

Steps

1. Confirm the stage and read the tree first. Establish the work is verified and delivery is the next step, then enumerate which of the target files already exist. This list decides everything that follows.
2. Gather the source material. Project scope, tech stack, entry points, build and test commands, and the commit history for the change log. Derive from the repository as it stands — a scaffold describing an intended project rather than the delivered one is actively misleading.
3. Obtain operator approval before writing. Present the exact list of files to be created and the files being skipped because they exist. See Approval.
4. Write only the missing files. Each existing target is skipped and reported by name.
5. Verify the instructions you just wrote. Run the build and test commands exactly as the README states them. A scaffold's commands are its only load-bearing claim, and an untested command block is the most common defect in a generated README — it is written from the plan rather than from a run.
6. Report what was created, what was skipped and why, and what remains for a human. Placeholders left for the operator are listed explicitly, never left to be discovered.