---
name: apt:prototype
description: "Question-driven throwaway prototyping with 5-rule discipline — LOGIC branch (terminal-app for state-machine validation) and UI branch (delegates to apt:mockup)"
apt-skill-version: {{APT_VERSION}}
stage: design
intent: design
when_to_use: "The user has a question that wants a runnable prototype rather than a plan — 'does this state machine work?' (LOGIC branch) or 'does this UI shape feel right?' (UI branch). Throwaway code by design; do NOT confuse this with apt:plan or apt:execute."
user_invocable: true
internal: false
spawns_agent: false
agent_name: null
task_context: create-new
default_track: STANDARD
default_execution_mode: step
execution_modes:
  - auto
  - step
allowed-tools: "Bash, Read, Write, Edit, Grep, Glob"
argument-hint: "apt:prototype [question]"
gates: []
config_keys:
  - coding.prototype_discipline
---

# Prototype — Question-Driven Throwaway Code

This skill ships throwaway code that answers ONE question. It is NOT a
planning artifact, NOT a feature, and NOT something to merge. The output
is a single-command-runnable prototype that lets the user feel whether
the question's answer is "yes" or "no", then gets thrown away.

**Aperant adoption attribution.** Discipline ported from 's
MIT-licensed `prototype` skill. Routes between two branches by
question-type; the UI branch delegates to Aperant's existing
`/apt:mockup` skill for HTML+Tailwind variants. The LOGIC branch and
the 5-rule discipline are new for Aperant.

## When to Use

- The user asks a question (not a "build me X" request) — "does this
  state machine work?", "does this UI shape feel right?", "would users
  find this discoverable?"
- A throwaway prototype is the cheapest answer (cheaper than designing,
  planning, building, then discovering the answer was "no")
- The answer can be felt by running the prototype, not just reasoning
  about it

## When NOT to Use

- The user has a feature request — use `/apt:plan` + `/apt:execute`
- The user wants a polished mockup to share — use `/apt:mockup` directly
  (the UI branch of this skill delegates there anyway)
- The user wants production code with tests — that's TDD-mode
  `/apt:execute --tdd`, not a prototype

## Branch routing

Inspect the user's question:

- **LOGIC branch** — triggers: "does this state machine work?", "does
  this control flow handle edge case X?", "can this protocol handle
  out-of-order messages?". Answer: a single-file terminal app the user
  can run with one command to feel the state transitions.
- **UI branch** — triggers: "does this UI shape feel right?", "is this
  flow discoverable?", "does this layout work on mobile?". Answer:
  delegate to `/apt:mockup --variants 3` for HTML+Tailwind parallel
  variants.

If the question is genuinely ambiguous, ask ONE clarifying question
("are you asking about behavior or appearance?") — do NOT enter a long
interview.

## The 5 Universal Rules (Aperant discipline, applies to both branches)

These five rules apply to EVERY prototype this skill produces. They are
load-bearing — violating them collapses the prototype into ceremony
disguised as a question.

1. **Throwaway-marked.** Every prototype file MUST carry a top-of-file
   comment: `// THROWAWAY PROTOTYPE — do not merge, do not extend, do
   not test.` This is not optional. Files without this marker drift into
   production code and the question never gets answered cleanly.

2. **Single-command-run.** The prototype runs with ONE command. No
   build step. No dependency install. `node prototype.mjs` or `pnpm dlx
   tsx prototype.ts` or `bash prototype.sh` — pick one and stop. If you
   reach for webpack, you're prototyping a build, not the question.

3. **No-persistence-default.** The prototype does NOT touch any
   persistent store (libSQL, Convex, localStorage, .aperant/state.json).
   Everything is in-memory. If persistence is part of the question,
   explicitly opt in via a tmpfile — never the project's actual stores.

4. **Skip-polish.** No error handling for impossible scenarios. No
   accessibility audit. No mobile responsive breakpoints unless the
   question is about mobile. No animation refinement. Polish is what
   you do AFTER the prototype answered "yes"; doing it now obscures
   whether the answer was actually "yes".

5. **Surface-state-transparently.** The prototype prints / renders its
   internal state at every step the user might want to inspect. A
   terminal app prints every state transition. A UI prototype shows
   the data shape next to the rendered output. The user must be able
   to SEE what's happening — they can't feel an answer to "does this
   work" if the state is hidden.

## LOGIC branch — terminal app for state-machine validation

When the question is about behavior / control flow / state machines /
protocols:

1. Read `LOGIC.md` for the discipline (ported from 's
   `prototype/LOGIC.md` with MIT attribution).
2. Write ONE file (e.g., `prototype.mjs`, `prototype.ts`, or
   `prototype.py`) that:
   - Models the state machine in code
   - Provides a command-line driver that fires transitions one at a
     time, printing each state
   - Includes a 5-10 turn scripted run at the bottom that exercises the
     interesting paths
3. Write a one-line invocation: `node prototype.mjs` (or whatever).
4. Verify: run it. The user reads the output, gets their answer, and
   the file is deleted.

## UI branch — delegates to apt:mockup

When the question is about layout / aesthetics / flow / discoverability:

1. Read `UI.md` for the discipline (ported from 's
   `prototype/UI.md` with MIT attribution).
2. Invoke `/apt:mockup --variants 3` as a sub-step. apt:mockup already
   enforces the UI-specific universal rules (zero-dep Tailwind CDN, no
   JS, throwaway HTML iterations preserved).
3. The 5 universal rules above still apply — verify each HTML file
   carries the `<!-- THROWAWAY PROTOTYPE -->` marker.

## Output contract

- Single prototype file (LOGIC) OR 3 HTML variants via apt:mockup (UI).
- No commits. No tests. No docs. The skill emits a final note: "Delete
  this when the question is answered."
- If the user wants to convert the prototype into real code, that's a
  separate `/apt:plan` invocation.
