A preserved method from https://github.com/mattpocock/skills at 3cca18b368ae, path skills/engineering/prototype, MIT. 22 of 208 source lines differ (11%), every difference claimed by an entry of the ledger with its reason. Entries: baseline-copies-2026-09-11, pull-2026-09-11, fold-2026-09-11, fold-walk-2026-09-11, series-s7-roster-2026-09-11, roster-keepers-2026-09-15, roster-keepers-fix-2026-09-15.
greenline renders its own frontmatter: quoted name and description, the description from the manifest override where one existed, no upstream activation flag
name: prototype
name: "prototype"
description: Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.
description: "Build a throwaway prototype, a spike, to answer one design question. Use when the user wants to sanity-check whether a state model or logic feels right, mock up a couple of UI options, or 'just try it and see'."
---
---
# Prototype
# Prototype
scopechangedfold-2026-09-11
The skill's scope opens the body in its own voice: a decision or plan dispatches it for one experimental question, it settles the disposable-or-ship distinction and uses the existing owner, a promising prototype never becomes production code silently, and it publishes no external issue and needs no tracker.
A decision or plan dispatches this method when one experimental question stands in its way: the requesting stage names the question, and the answer goes back to it. Establish the question, which branch below it needs, and whether the result is disposable or intended to ship; resolve that distinction when the request leaves it open, and use the existing task's owner. A promising prototype does not silently become production code: the validated decision moves into the real code by the normal path, and the disposable code never enters the shipping source tree. This method publishes no external issue and needs no tracker.
A prototype is **throwaway code that answers a question**. The question decides the shape.
A prototype is **throwaway code that answers a question**. The question decides the shape.
## Pick a branch
## Pick a branch
7 unchanged lines
Identify which question is being answered, using the user's prompt, the surrounding code, or by asking if the user is around:
Identify which question is being answered, using the user's prompt, the surrounding code, or by asking if the user is around:
- **"Does this logic / state model feel right?"** → [LOGIC.md](LOGIC.md). Build a single shareable HTML file (free-play buttons plus tabbed guided walkthroughs) that pushes the state machine through cases that are hard to reason about on paper, and that a non-developer can drive.
- **"Does this logic / state model feel right?"** → [LOGIC.md](LOGIC.md). Build a single shareable HTML file (free-play buttons plus tabbed guided walkthroughs) that pushes the state machine through cases that are hard to reason about on paper, and that a non-developer can drive.
- **"What should this look like?"** → [UI.md](UI.md). Generate several radically different UI variations on a single route, switchable via a URL search param and a floating bottom bar.
- **"What should this look like?"** → [UI.md](UI.md). Generate several radically different UI variations on a single route, switchable via a URL search param and a floating bottom bar.
The two branches produce very different artifacts, so getting this wrong wastes the whole prototype. If the question is genuinely ambiguous and the user isn't reachable, default to whichever branch better matches the surrounding code (a backend module → logic; a page or component → UI) and state the assumption at the top of the prototype.
The two branches produce very different artifacts, so getting this wrong wastes the whole prototype. If the question is genuinely ambiguous and the user isn't reachable, default to whichever branch better matches the surrounding code (a backend module → logic; a page or component → UI) and state the assumption at the top of the prototype.
## Rules that apply to both
## Rules that apply to both
methodchangedseries-s7-roster-2026-09-11
upstream's rules 1 and 2 place prototype code next to the module it prototypes and add a task-runner entry; greenline keeps disposable code out of the shipping tree (scratch, the owner's evidence home, or a throwaway checkout) and adds no runner entry, which changes where the method works Confirmed by the operator on 2026-09-11 (method-rulings.md).
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.
1. **Throwaway from day one, and clearly marked as such.** Keep the prototype code out of the shipping source tree: a runnable experiment lives in `.greenline/tmp/prototype/`, in the owner's evidence home, or in an isolated throwaway checkout of the project when it needs the real modules and pages around it (mirror the project's module and routing conventions there, so context stays obvious), and 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. **Trivial to run.** A UI prototype starts from one command in the project's task runner: `pnpm <name>`, `python <path>`, `bun <path>`, etc. A logic demo is a single HTML file the user double-clicks. Either way, no thinking required to start it.
2. **Trivial to run.** A UI prototype starts from one documented command run from the experiment's directory or isolated checkout with the tools already available: `pnpm <name>`, `python <path>`, `bun <path>`, etc.; the shipping task runner gains no prototype entry. A logic demo is a single HTML file the user double-clicks. Either way, no thinking required to start it.
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.
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.
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.
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.
locationchangedroster-keepers-fix-2026-09-15
Rule 6 and the Handoff agree: the relied-on copy is promoted into the owner's evidence home and cited there, a throwaway branch exists only for a prototype built in an isolated checkout and its pointer is context, never evidence; the owning ticket and an initiative's prototypes/PROTO-NNN.md remain the greenline homes; carried from roster-keepers-2026-09-15 (J-8's fix, 2026-09-15)
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.
6. **Capture it when done.** Fold any validated decision into the real code, then capture the prototype itself as a **primary source**: copy what the decision relies on into the owning ticket's evidence home first, and cite that copy; a prototype built in an isolated checkout may also be kept on a throwaway branch, out of main, with a context pointer to that branch on the owning ticket, `.greenline/work/tickets/TKT-NNN.md`, which is context and never evidence. Capture the answer too (the verdict, the question it settled, and its limits) in the ticket or a commit; when an initiative owns the question, its `prototypes/PROTO-NNN.md` carries the question, the answer, the limits and the branch pointer. The main branch keeps only the validated decision.
## Handoff
Consumes: one experimental question and whether its result is disposable or meant to ship, from the requesting decision or plan
Produces: prototypes/PROTO-NNN.md in the owning initiative, or the answer on the owning ticket with the relied-on copy in its evidence home; for a prototype built in an isolated checkout, a throwaway branch with its pointer as context; disposable code never in shipping implementation
Evidence at: the owner's evidence home, where the relied-on copy is promoted from .greenline/tmp/prototype/ or an isolated throwaway checkout; a throwaway branch, when one exists, is a context pointer and never evidence
Returns to: the requesting decision or plan, with the answer and its limits
agents/openai.yaml
harnessremoved filebaseline-copies-2026-09-11
the renderer generates agents/openai.yaml from the manifest; the vendored copy is not projected
interface:
display_name: "Prototype"
short_description: "Prototype to answer a design question"
The timeline
Each entry that touched this method, with the differences it claimed as they stood at its commit, read from the repository's history.
2026-09-11baseline-copies-2026-09-11
the cutover to an edited copy (ADR 0039): the composed output written as the copy, every difference from upstream claimed with the reason of the overlay that produced it
SKILL.md
harnesschangedbaseline-copies-2026-09-11
greenline renders its own frontmatter: quoted name and description, the description from the manifest override where one existed, no upstream activation flag
name: prototype
name: "prototype"
description: Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.
description: "Build a throwaway prototype, a spike, to answer one design question. Use when the user wants to sanity-check whether a state model or logic feels right, mock up a couple of UI options, or 'just try it and see'."
lifecyclechangedbaseline-copies-2026-09-11
greenline prelude, to fold: one experimental question and the disposable-or-ship distinction; the experiment lives in the owner's evidence or scratch space or an isolated checkout; the task runner entry and the issue mean the local ticket
**greenline prelude: one experimental question.** Establish the question, the LOGIC or UI branch the method needs, and whether the result is disposable or intended to ship. Resolve that distinction when the request leaves it open. Use the existing task's owner. **Replace rule 1's “Locate the prototype code close to where it will actually
be used” and throwaway-route placement sentences:** keep runnable experiments
in the owner's evidence or scratch space, or in an isolated throwaway checkout.
Mirror the project's module and routing conventions inside that isolated
checkout when the experiment needs them; do not add disposable code to the
shipping source tree. Typed work artifacts record the question and result.
**Replace rule 2's “A UI prototype starts from one command in the project's
task runner” sentence:** provide one documented command from the experiment's
directory or isolated checkout using the available tools. The shipping task
runner need not acquire a prototype entry. The logic demo remains a
self-contained HTML file opened directly. A promising prototype does not silently become production code. In rule 6,
`implementation issue` and the result's `issue` mean the owning local ticket
under WORK.md; put the branch pointer and answer there. The method publishes
no external issue and requires no tracker integration.
lifecyclechangedbaseline-copies-2026-09-11
greenline completion, to fold: retain question, answer, limits and a reproducible pointer under the work contract; disposable code stays out of shipping implementation
## greenline completion: the experimental result
Retain the question, answer, limits, and a reproducible pointer to the relied-on experiment under the shared work contract. An initiative can use a prototype artifact; a compact ticket can link its experimental evidence. Record actual source use in the contributor's ledger and fold supported conclusions into the requesting decision or plan. Keep disposable code separate from shipping implementation, and return to the same workflow within its grant.
agents/openai.yaml
harnessremoved filebaseline-copies-2026-09-11
the renderer generates agents/openai.yaml from the manifest; the vendored copy is not projected
interface:
display_name: "Prototype"
short_description: "Prototype to answer a design question"
2026-09-11pull-2026-09-11
pin advance to 3cca18b: upstream moved with no change under the vendored paths
2026-09-11fold-2026-09-11
The prelude's replacement instructions and the completion are folded into the rules they addressed: rule 1 and 2 name greenline's experiment homes and command, rule 6 names the owning ticket and the initiative's prototype artifact, and a Handoff section returns the answer to the requesting decision or plan.
SKILL.md
scopechangedfold-2026-09-11
The skill's scope opens the body in its own voice: a decision or plan dispatches it for one experimental question, it settles the disposable-or-ship distinction and uses the existing owner, a promising prototype never becomes production code silently, and it publishes no external issue and needs no tracker.
A decision or plan dispatches this method when one experimental question stands in its way: the requesting stage names the question, and the answer goes back to it. Establish the question, which branch below it needs, and whether the result is disposable or intended to ship; resolve that distinction when the request leaves it open, and use the existing task's owner. A promising prototype does not silently become production code: the validated decision moves into the real code by the normal path, and the disposable code never enters the shipping source tree. This method publishes no external issue and needs no tracker.
locationchangedfold-2026-09-11
Rules 1 and 2 in place: runnable experiments live in .greenline/tmp/prototype/, the owner's evidence home or an isolated throwaway checkout that mirrors the project's module and routing conventions, never in the shipping source tree, and a UI prototype starts from one documented command run there with the tools already available, so the shipping task runner gains no prototype entry; upstream's 'close to where it will be used' and 'in the project's task runner' would put disposable code and a runner entry into the shipped tree.
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.
1. **Throwaway from day one, and clearly marked as such.** Keep the prototype code out of the shipping source tree: a runnable experiment lives in `.greenline/tmp/prototype/`, in the owner's evidence home, or in an isolated throwaway checkout of the project when it needs the real modules and pages around it (mirror the project's module and routing conventions there, so context stays obvious), and 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. **Trivial to run.** A UI prototype starts from one command in the project's task runner: `pnpm <name>`, `python <path>`, `bun <path>`, etc. A logic demo is a single HTML file the user double-clicks. Either way, no thinking required to start it.
2. **Trivial to run.** A UI prototype starts from one documented command run from the experiment's directory or isolated checkout with the tools already available: `pnpm <name>`, `python <path>`, `bun <path>`, etc.; the shipping task runner gains no prototype entry. A logic demo is a single HTML file the user double-clicks. Either way, no thinking required to start it.
locationchangedfold-2026-09-11
Rule 6's implementation issue is the owning ticket .greenline/work/tickets/TKT-NNN.md, and an initiative's prototypes/PROTO-NNN.md carries the question, answer, limits and the throwaway-branch pointer, so the result has a greenline home and no external tracker; the Handoff section (ADR 0039) names what is consumed, produced and returned so the chain closes.
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.
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 owning ticket, `.greenline/work/tickets/TKT-NNN.md`. Capture the answer too (the verdict, the question it settled, and its limits) in the ticket or a commit; when an initiative owns the question, its `prototypes/PROTO-NNN.md` carries the question, the answer, the limits and the branch pointer. The main branch keeps only the validated decision.
## Handoff
Consumes: one experimental question and whether its result is disposable or meant to ship, from the requesting decision or plan
Produces: prototypes/PROTO-NNN.md in the owning initiative, or the answer and branch pointer on the owning ticket; disposable code on a throwaway branch, never in shipping implementation
Evidence at: .greenline/tmp/prototype/, the owner's evidence home, or an isolated throwaway checkout, with the throwaway branch as the reproducible pointer
Returns to: the requesting decision or plan, with the answer and its limits
2026-09-11fold-walk-2026-09-11
the coherence walk: the placement rule re-kinded as a method edit
SKILL.md
methodchangedfold-walk-2026-09-11
upstream's rules 1 and 2 place prototype code next to the module it prototypes and add a task-runner entry; greenline keeps disposable code out of the shipping tree (scratch, the owner's evidence home, or a throwaway checkout) and adds no runner entry, which changes where the method works
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.
1. **Throwaway from day one, and clearly marked as such.** Keep the prototype code out of the shipping source tree: a runnable experiment lives in `.greenline/tmp/prototype/`, in the owner's evidence home, or in an isolated throwaway checkout of the project when it needs the real modules and pages around it (mirror the project's module and routing conventions there, so context stays obvious), and 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. **Trivial to run.** A UI prototype starts from one command in the project's task runner: `pnpm <name>`, `python <path>`, `bun <path>`, etc. A logic demo is a single HTML file the user double-clicks. Either way, no thinking required to start it.
2. **Trivial to run.** A UI prototype starts from one documented command run from the experiment's directory or isolated checkout with the tools already available: `pnpm <name>`, `python <path>`, `bun <path>`, etc.; the shipping task runner gains no prototype entry. A logic demo is a single HTML file the user double-clicks. Either way, no thinking required to start it.
2026-09-11series-s7-roster-2026-09-11
The operator's ruling on the method-class edits put to them by the S3 fold: the edit is kept and re-recorded with the ruling as its authority.
SKILL.md
methodchangedseries-s7-roster-2026-09-11
upstream's rules 1 and 2 place prototype code next to the module it prototypes and add a task-runner entry; greenline keeps disposable code out of the shipping tree (scratch, the owner's evidence home, or a throwaway checkout) and adds no runner entry, which changes where the method works Confirmed by the operator on 2026-09-11 (method-rulings.md).
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.
1. **Throwaway from day one, and clearly marked as such.** Keep the prototype code out of the shipping source tree: a runnable experiment lives in `.greenline/tmp/prototype/`, in the owner's evidence home, or in an isolated throwaway checkout of the project when it needs the real modules and pages around it (mirror the project's module and routing conventions there, so context stays obvious), and 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. **Trivial to run.** A UI prototype starts from one command in the project's task runner: `pnpm <name>`, `python <path>`, `bun <path>`, etc. A logic demo is a single HTML file the user double-clicks. Either way, no thinking required to start it.
2. **Trivial to run.** A UI prototype starts from one documented command run from the experiment's directory or isolated checkout with the tools already available: `pnpm <name>`, `python <path>`, `bun <path>`, etc.; the shipping task runner gains no prototype entry. A logic demo is a single HTML file the user double-clicks. Either way, no thinking required to start it.
2026-09-15roster-keepers-2026-09-15
Rule 6 committed every prototype to a branch and cited it, against the runtime's scratch law, which J-9 made the keeper (the audit J-5, finding 9; found again by J-10): what a decision relies on is copied into the ticket's evidence home first, a branch only for an isolated-checkout prototype, as context. The earlier claim is carried forward.
SKILL.md
locationchangedroster-keepers-2026-09-15
Rule 6's implementation issue is the owning ticket .greenline/work/tickets/TKT-NNN.md, and an initiative's prototypes/PROTO-NNN.md carries the question, answer, limits and the branch pointer; the relied-on prototype is copied into the ticket's evidence home first and cited there, and a throwaway branch is kept only for a prototype built in an isolated checkout, its pointer context and never evidence, matching .greenline/WORK.md; carried from fold-2026-09-11 (J-8, 2026-09-15)
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.
6. **Capture it when done.** Fold any validated decision into the real code, then capture the prototype itself as a **primary source**: copy what the decision relies on into the owning ticket's evidence home first, and cite that copy; a prototype built in an isolated checkout may also be kept on a throwaway branch, out of main, with a context pointer to that branch on the owning ticket, `.greenline/work/tickets/TKT-NNN.md`, which is context and never evidence. Capture the answer too (the verdict, the question it settled, and its limits) in the ticket or a commit; when an initiative owns the question, its `prototypes/PROTO-NNN.md` carries the question, the answer, the limits and the branch pointer. The main branch keeps only the validated decision.
## Handoff
Consumes: one experimental question and whether its result is disposable or meant to ship, from the requesting decision or plan
Produces: prototypes/PROTO-NNN.md in the owning initiative, or the answer and branch pointer on the owning ticket; disposable code on a throwaway branch, never in shipping implementation
Evidence at: .greenline/tmp/prototype/, the owner's evidence home, or an isolated throwaway checkout, with the throwaway branch as the reproducible pointer
Returns to: the requesting decision or plan, with the answer and its limits
2026-09-15roster-keepers-fix-2026-09-15
The review REV-J-8 (Spec 2) found the Handoff's Produces and Evidence at lines still requiring a branch pointer unconditionally; they now condition the branch and its pointer on the isolated-checkout case and name the promoted copy in the owner's evidence home as the evidence. The earlier claim is carried forward.
SKILL.md
locationchangedroster-keepers-fix-2026-09-15
Rule 6 and the Handoff agree: the relied-on copy is promoted into the owner's evidence home and cited there, a throwaway branch exists only for a prototype built in an isolated checkout and its pointer is context, never evidence; the owning ticket and an initiative's prototypes/PROTO-NNN.md remain the greenline homes; carried from roster-keepers-2026-09-15 (J-8's fix, 2026-09-15)
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.
6. **Capture it when done.** Fold any validated decision into the real code, then capture the prototype itself as a **primary source**: copy what the decision relies on into the owning ticket's evidence home first, and cite that copy; a prototype built in an isolated checkout may also be kept on a throwaway branch, out of main, with a context pointer to that branch on the owning ticket, `.greenline/work/tickets/TKT-NNN.md`, which is context and never evidence. Capture the answer too (the verdict, the question it settled, and its limits) in the ticket or a commit; when an initiative owns the question, its `prototypes/PROTO-NNN.md` carries the question, the answer, the limits and the branch pointer. The main branch keeps only the validated decision.
## Handoff
Consumes: one experimental question and whether its result is disposable or meant to ship, from the requesting decision or plan
Produces: prototypes/PROTO-NNN.md in the owning initiative, or the answer on the owning ticket with the relied-on copy in its evidence home; for a prototype built in an isolated checkout, a throwaway branch with its pointer as context; disposable code never in shipping implementation
Evidence at: the owner's evidence home, where the relied-on copy is promoted from .greenline/tmp/prototype/ or an isolated throwaway checkout; a throwaway branch, when one exists, is a context pointer and never evidence
Returns to: the requesting decision or plan, with the answer and its limits