prototype: simplify to single primary-source idea; dedup branch files

Drop the secondary-source label — the actionable distinction is just
that the prototype is a primary source to retain on a throwaway branch.
Collapse the re-descriptions in LOGIC/UI so they point to SKILL for the
disposal concept and add only branch-specific nuance.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.changeset/prototype-primary-secondary-source.md

@@ -1,5 +0,0 @@
----
-"mattpocock-skills": minor
----
-
-Reword how the **`prototype`** skill lets go of its artifacts, around a **primary vs secondary source** distinction. The _secondary source_ is the distilled answer (issue/ADR/commit) — still the part that matters most. The _primary source_ is the prototype itself: rather than deleting it, it's now preserved as runnable evidence on a throwaway branch (`prototype/<name>`) linked from the relevant issue, never merged, so the main branch keeps only the validated decision.

.changeset/prototype-primary-source.md

@@ -0,0 +1,5 @@
+---
+"mattpocock-skills": minor
+---
+
+Reword how the **`prototype`** skill lets go of its artifacts around a single idea: **the prototype is a primary source**. Rather than being deleted once it's answered its question, the prototype is kept as runnable evidence on a throwaway branch (`prototype/<name>`) linked from the relevant issue, never merged, so the main branch keeps only the validated decision. The answer (verdict + question) is still captured durably in an issue/ADR/commit.

docs/engineering/prototype.md

@@ -31,11 +31,11 @@ The question decides the shape, and there are two shapes:
 
 Picking the wrong branch wastes the whole prototype, so the question comes first. Both branches keep state in memory, run from one command, and surface the full state on every step.
 
-## Primary and secondary source
+## Keep the prototype as a primary source
 
-A finished prototype leaves two things, and they're kept differently. The **secondary source** is the _answer_ — the verdict plus the question it settled, distilled into durable prose (a commit message, an ADR, an issue). That's what future readers consult, and it's the part that matters most. The **primary source** is the _prototype itself_ — the runnable evidence the answer came from.
+A finished prototype leaves two things. The **answer** — the verdict plus the question it settled — is what you capture durably (a commit message, an ADR, an issue). The **prototype itself is a primary source** — the runnable evidence the answer came from.
 
-The prototype doesn't belong in the main repo: no tests, no error handling, nothing to maintain. But that's not a reason to destroy it. Once the answer is captured, fold any validated decision into the real code, then move the prototype onto a throwaway branch linked from the relevant issue — never merged. The main branch stays clean; the raw exploration stays one click away for anyone who wants to re-run it. A prototype left rotting in the main branch has outlived its purpose — a prototype preserved as a primary source on a side branch hasn't.
+The prototype doesn't belong in the main repo: no tests, no error handling, nothing to maintain. But that's not a reason to destroy it. Once the answer is captured, fold any validated decision into the real code, then move the prototype onto a throwaway branch linked from the relevant issue — never merged. The main branch stays clean; the raw exploration stays one click away for anyone who wants to re-run it. A prototype left rotting in the main branch has outlived its purpose — a prototype kept as a primary source on a side branch hasn't.
 
 ## Where it fits
 

skills/engineering/prototype/LOGIC.md

@@ -36,7 +36,7 @@ The right shape depends on the question:
 
 Pick whichever shape best fits the question being asked, *not* whichever is easiest to wire to a TUI. Keep it pure: no I/O, no terminal code, no `console.log` for control flow. The TUI imports it and calls into it; nothing flows the other direction.
 
-This is what makes the prototype useful past its own lifetime. When the question's been answered, the validated reducer / machine / function set can be lifted into the real module — the TUI shell gets deleted.
+This is what makes the prototype useful past its own lifetime: when the question's been answered, the validated reducer / machine / function set can be lifted into the real module on its own.
 
 ### 4. Build the smallest TUI that exposes the state
 
@@ -66,9 +66,9 @@ If the host project has no task runner, just put the command at the top of the p
 
 Give the user the run command. They'll drive it themselves; the interesting moments are when they say "wait, that shouldn't be possible" or "huh, I assumed X would be different" — those are the bugs in the _idea_, which is the whole point. If they want new actions added, add them. Prototypes evolve.
 
-### 7. Capture the answer
+### 7. Capture the answer and let go
 
-When the prototype has done its job, capture the **answer** — the secondary source — somewhere durable (issue, ADR, commit message). If the user is around, ask what it taught them; if not, leave a `NOTES.md` next to the prototype so the answer can be filled in (or filled in by you, if you've watched the session). Then let go of the prototype the way the [SKILL](SKILL.md) describes: fold any validated logic into the real module, and move the prototype itself — the primary source — onto a throwaway branch linked from the relevant issue rather than deleting it.
+Once the prototype has answered its question, capture the answer and dispose of the prototype the way the [SKILL](SKILL.md) describes. The logic-specific mapping: the validated reducer / machine / function set lifts into the real module (the decision, absorbed); the TUI shell rides along to the throwaway branch that keeps the prototype as a primary source.
 
 ## Anti-patterns
 

skills/engineering/prototype/SKILL.md

@@ -23,14 +23,14 @@ The two branches produce very different artifacts — getting this wrong wastes
 3. **No persistence by default.** State lives in memory. Persistence is the thing the prototype is _checking_, not something it should depend on. If the question explicitly involves a database, hit a scratch DB or a local file with a clear "PROTOTYPE — wipe me" name.
 4. **Skip the polish.** No tests, no error handling beyond what makes the prototype _runnable_, no abstractions. The point is to learn something fast and then let it go.
 5. **Surface the state.** After every action (logic) or on every variant switch (UI), print or render the full relevant state so the user can see what changed.
-6. **Let go of it when done.** Fold any validated decision into the real code, then preserve the prototype itself as a **primary source** — committed to a throwaway branch linked from the relevant issue, never merged to main (see _Primary vs secondary source_ below). The main branch keeps only the validated decision.
+6. **Let go of it when done.** Fold any validated decision into the real code, then keep the prototype itself as a **primary source** — committed to a throwaway branch linked from the relevant issue, never merged to main (see _Keep it as a primary source_ below). The main branch keeps only the validated decision.
 
-## When done: primary vs secondary source
+## When done: keep it as a primary source
 
-A finished prototype leaves two things behind, and they're kept differently.
+Two things come out of a finished prototype.
 
-- **The secondary source is the _answer_** — the verdict plus the question it settled, distilled into durable prose: an issue comment, an ADR, or a commit message. This is what future readers actually consult, and it's the part that matters most. If the user is around, capturing it is a quick conversation; if not, leave a placeholder (a `NOTES.md` next to the prototype) so the verdict can be filled in — by them, or by you if you watched the session — before you move the code.
+- **The answer** — the verdict plus the question it settled — is what you capture durably: an issue comment, an ADR, or a commit message. If the user is around, that's a quick conversation; if not, leave a placeholder (a `NOTES.md` next to the prototype) so the verdict can be filled in before you move the code.
 
-- **The primary source is the _prototype itself_** — the runnable artifact the answer came from. It's the evidence behind the verdict, so you don't delete it; but with no tests and no maintenance story, it doesn't belong in the main repo either. Once the answer is captured, get the prototype out: commit it to a throwaway branch (e.g. `prototype/<name>`), push it, and link that branch from the relevant issue. Never merge it. The main branch keeps only the validated decision folded into real code; the raw exploration stays on the branch, one click away for anyone who wants to re-run it.
+- **The prototype itself is a primary source** — the runnable evidence the answer came from. With no tests and no maintenance story it doesn't belong in the main repo, but that's not a reason to delete it. Once the answer's captured, get the prototype out: commit it to a throwaway branch (e.g. `prototype/<name>`), push it, and link that branch from the relevant issue. Never merge it. The main branch keeps only the validated decision folded into real code; the raw exploration stays on the branch, one click away for anyone who wants to re-run it.
 
-This is distinct from _absorbing_: lifting a validated reducer, state machine, or UI direction into the real module keeps the **decision**, not the prototype. The throwaway branch is what preserves the primary source.
+This is distinct from _absorbing_: lifting a validated reducer, state machine, or UI direction into the real module keeps the **decision**, not the prototype. The throwaway branch is what keeps the prototype as a primary source.

skills/engineering/prototype/UI.md

@@ -97,12 +97,12 @@ Surface the URL (and the `?variant=` keys). The user will flip through whenever
 
 ### 6. Capture the answer and clean up
 
-Once a variant has won, capture the **answer** — the secondary source: which variant and why (commit message, ADR, issue, or a `NOTES.md` next to the prototype if running AFK and the user hasn't responded yet). Then fold the winner into the real code and get the prototype scaffolding out of the main branch:
+Once a variant has won, capture the answer — which variant and why — and dispose of the prototype the way the [SKILL](SKILL.md) describes. Fold the winner into the real code and get the rest out of the main branch:
 
 - **Sub-shape A** — fold the winner into the existing page; drop the losing variants and the switcher from main.
 - **Sub-shape B** — promote the winning variant to a real route; drop the throwaway route and the switcher from main.
 
-Don't leave variant components or the switcher lying around in the main branch — they rot fast and confuse the next reader. But don't just destroy them either: the full set of variants is the primary source, so preserve the prototype on a throwaway branch linked from the relevant issue (see [SKILL](SKILL.md)) before you strip it out of main.
+The full set of variants is the primary source, so it lands on the throwaway branch, not the bin — variant components and the switcher left in the main branch rot fast and confuse the next reader.
 
 ## Anti-patterns