From fa460cbf095a893d14bf41d3db7798cada500259 Mon Sep 17 00:00:00 2001 From: Matt Pocock Date: Fri, 10 Jul 2026 11:35:29 +0100 Subject: [PATCH] prototype: drop the vestigial "let it go" Rule 4 is about skipping polish, not the prototype's fate; the trailing "then let it go" was a leftover from the old delete-it framing and now misreads as discard, contradicting capture-as-primary-source. Cut it, and rename LOGIC step 7 off "let go". Co-Authored-By: Claude Opus 4.8 (1M context) --- skills/engineering/prototype/LOGIC.md | 2 +- skills/engineering/prototype/SKILL.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/skills/engineering/prototype/LOGIC.md b/skills/engineering/prototype/LOGIC.md index c86d1bd..fe9a2c2 100644 --- a/skills/engineering/prototype/LOGIC.md +++ b/skills/engineering/prototype/LOGIC.md @@ -66,7 +66,7 @@ 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 and let go +### 7. Capture the answer and the prototype Once the prototype has answered its question, capture the answer, then capture 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. diff --git a/skills/engineering/prototype/SKILL.md b/skills/engineering/prototype/SKILL.md index 62c495c..e75d533 100644 --- a/skills/engineering/prototype/SKILL.md +++ b/skills/engineering/prototype/SKILL.md @@ -21,6 +21,6 @@ The two branches produce very different artifacts — getting this wrong wastes 1. **Throwaway from day one, and clearly marked as such.** Locate the prototype code close to where it will actually be used (next to the module or page it's prototyping for) so context is obvious — but name it so a casual reader can see it's a prototype, not production. For throwaway UI routes, obey whatever routing convention the project already uses; don't invent a new top-level structure. 2. **One command to run.** Whatever the project's existing task runner supports — `pnpm `, `python `, `bun `, etc. The user must be able to start it without thinking. 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. +4. **Skip the polish.** No tests, no error handling beyond what makes the prototype _runnable_, no abstractions. The point is to learn something fast. 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. **Capture it when done.** Fold any validated decision into the real code, then capture the prototype itself as a **primary source**: commit it to a throwaway branch, out of main, and leave a context pointer to that branch on the implementation issue. Capture the answer too — the verdict and the question it settled — in the issue or a commit. The main branch keeps only the validated decision.