spinout · git:20260815.957b21b · 2026-08-15 · sha256 51cd8d84a5202a43
spinout git:20260815.957b21bA
Immutable. This exact content is served forever at /api/v1/blob/51cd8d84a5202a43.
--- name: spinout user-invocable: true model: sonnet description: > Use when extracting a project into its own repo — a venture spinout (e.g. a product leaving its incubator repo) or a sanitized content-snapshot fork. Guided 5-step runbook: target sphere + path, confidentiality/sanitize check, copy + fresh git init, SNAPSHOT-FREEZE marker in the source repo, remotes + registration. Trigger on 'spin out X', 'extract this into its own repo', 'fork X sanitized'. --- # spinout — Guided Project-Extraction Runbook ## Status: Deliberately Not Scripted This is a 5-phase interactive runbook, not a CLI wrapper. Automate only after 2-3 hand-runs have stabilized the pattern — spinout is a low-frequency, high-stakes operation (new remote, fresh history, a frozen marker left behind in the source repo), and premature scripting bakes wrong defaults (wrong sphere, wrong sanitize scope, wrong remote layout) into something expensive to undo. See #730 / H2. ## Phase 0: Bootstrap Gate Read `skills/_shared/bootstrap-gate.md` and execute the gate check. If the gate is CLOSED, invoke `skills/bootstrap/SKILL.md` and wait for completion before proceeding. If the gate is OPEN, continue to Phase 1. ## Phase 1: Target + Sphere (AUQ) Ask via `AskUserQuestion` (per `.claude/rules/ask-via-tool.md` AUQ-001): - **Destination path** — where the new repo will live on disk. - **Sphere** — which account/host the new repo belongs to. Sphere conventions are **host-local**, not hardcoded here: read the operator's global `CLAUDE.md` (e.g. `~/.claude/CLAUDE.md`) for the "Verzeichnis = Account" mapping (private vs. org vs. ventures trees, or whatever the host documents) and offer those as options. - **Extraction type** — `venture-spinout` (a product leaving its incubator repo, gets a live remote and its own backlog) or `sanitized-snapshot` (a frozen, sanitized fork of content/code with no independent forward development expected). Do not proceed to Phase 2 without explicit confirmation of all three. ## Phase 2: Confidentiality / Sanitize Check (HARD-GATE) <HARD-GATE> No copy happens until this checklist is confirmed by the operator. Do not rationalize past it because "it's all internal anyway." </HARD-GATE> Checklist: - **Secrets/tokens** — run gitleaks (or the repo's existing pre-commit scanner) over the target sub-path before copying. - **Live-infra references** — hostnames, internal URLs, deploy targets that should not leak into a spun-out repo. - **Internal-only docs** — anything under a private-only doc tree that should not travel. - **PII** — names, emails, customer data in fixtures or sample content. **Inertness declaration pattern:** infra-coupled scripts that will simply run empty in the new repo without their source tokens/infra (not broken, just inert there) get TABULATED in the FORK-NOTES (Phase 4) rather than silently deleted — deletion loses information a future maintainer needs; the table makes the inertness an explicit, reviewable fact. ## Phase 3: Copy + Fresh git init - Directory copy of the target sub-path — deliberately **not** `git subtree split` or `git filter-repo`. No shared history travels with the spinout by design; the new repo starts clean. - Exclude build/dependency artifacts the same way a worktree would (`node_modules`, `dist`, `.git`, lockfile-derived caches). - `git init` fresh in the destination. - Add a provenance header to the new repo's `README.md` / `CLAUDE.md` (or `AGENTS.md` on Codex CLI): source repo, source path, extraction date, extraction type. ## Phase 4: SNAPSHOT-FREEZE Marker in the Source Repo Write a `FORK-NOTES.md` (or `SNAPSHOT.md`) at the **original location** in the source repo — the copy left behind, not the new repo. Contents: - Provenance: source path, spinout date, "frozen — SSOT moved to `<new-repo>`". - Remote map: where the new repo now lives (sphere + URL). - Inertness table from Phase 2 (script → why it's inert here, not broken). The corpus left behind at the original location is FROZEN from this point — cross-reference `.claude/rules/development.md` § Corpus Freeze Marker for the convention. ## Phase 5: Remotes + Registration (AUQ) Confirm each write via `AskUserQuestion` before executing: - Create the new repo's remote(s) per sphere (push-URL discipline — any helper remote used only for cross-host fetch should have push `DISABLED` where that pattern applies). - Register the new repo in the vault/portfolio index if one exists. - Optionally seed an initial issue backlog in the new repo. ## Anti-Patterns - Scripting this runbook before the pattern has stabilized over 2-3 hand-runs. - Skipping the Phase 2 sanitize gate "because it's internal anyway." - Carrying shared git history into the spinout (`subtree`/`filter-repo`) — the new repo starts clean by design. - Continuing to develop the source copy after Phase 4 instead of treating it as frozen. ## See Also - `commands/spinout.md` — slash-command entry point. - `skills/_shared/bootstrap-gate.md` — Phase 0 gate contract. - `.claude/rules/ask-via-tool.md` — AUQ-001 (every user decision goes through the tool, not prose). - `.claude/rules/parallel-sessions.md` § PSA-003 — destructive-action safeguards apply to any write in Phase 3/4/5.