Two small documentation gaps, hit in one scaffolding session:
1. /new-repo into a folder that already has content
The skill is written as "create a new directory and fill it". Scaffolding into a directory that already contains files (e.g. a design doc written before repo genesis) works in practice, but nothing documents it: what to check first, collision/overwrite rules vs. pre-existing files, and whether the pre-existing content joins the scaffold commit or gets its own. A short "adopting an existing directory" subsection would stop future sessions improvising.
2. Branding names vs. the kebab-case default
/new-repo specifies the repo name as kebab-case. A deliberately branded name (e.g. a camelCase product name) is a legitimate user choice, but since the docs never say so, a by-the-book agent may argue with the user about their own product name. Suggest one line in the naming conventions: a deliberate branding name is an allowed exception — record it in ADR-0001.
🤖 Generated with Claude Code
Two small documentation gaps, hit in one scaffolding session:
1.
/new-repointo a folder that already has contentThe skill is written as "create a new directory and fill it". Scaffolding into a directory that already contains files (e.g. a design doc written before repo genesis) works in practice, but nothing documents it: what to check first, collision/overwrite rules vs. pre-existing files, and whether the pre-existing content joins the scaffold commit or gets its own. A short "adopting an existing directory" subsection would stop future sessions improvising.
2. Branding names vs. the kebab-case default
/new-repospecifies the repo name as kebab-case. A deliberately branded name (e.g. a camelCase product name) is a legitimate user choice, but since the docs never say so, a by-the-book agent may argue with the user about their own product name. Suggest one line in the naming conventions: a deliberate branding name is an allowed exception — record it in ADR-0001.🤖 Generated with Claude Code