scaffoldinglisted

# Scaffolding How to set up, build out, and extend repos the way Fabrizio's fleet does — and how to behave in repos he doesn't own. ## Start at the gate — is the repo his? **The first thing this plugin does is determine ownership**, because everything else depends on it — and namespace alone doesn't settle it (he forks third-party repos into his namespace to contribute). See `references/owned-vs-third-party.md`. - **Owned** (his, verified not a fork) → adopt his conventions at repo level. - **Third-party** (a fork, or someone else's project) → this plugin does **nothing** proactive: adopt nothing into the repo, work within its own conventions, and adopt his plugins or CI only with his **explicit consent**. ## In an owned repo - **Building out a fresh repo** → bring it to standard *from the start* (core plugins, initial `CLAUDE.md`, Diátaxis docs + a build-out plan, content stubbed together with the plugin that governs it). See `references/building-out-a-repo.md`. - **Extending an existing repo** → spot conventions it hasn't adopted (or restates locally) and *suggest* them as a non-blocking prerequisite or follow-up, without derailing the current task. See `references/extending-a-repo.md`. ## The helper repos Shared/infrastructure repos you `add_repo` when a task needs them and remove once merged — `github-workflows` (shared CI), `claude-plugins` (these plugins), `terraform-github` (repos-as-Terraform). Which is which, how to adopt the shared CI, when *not* to prom