prototype

Prototype

A prototype is throwaway code that answers one question. Write the question down first, in one paragraph at the top of the prototype where the reader sees it. Then build the smallest thing that answers it.

Two modes

Pick by asking: does the prototype need the real app around it to be judged?

• Standalone (default). Plain HTML/CSS/JS, no framework, no bundler, no server. One file per prototype, saved in the task folder per the aiwork-protocol skill: prototype/index.html, or prototype/{name}.html for several. Everything inline so it opens by double-click and can be sent to anyone. Use for logic and state models, and for UI ideas that can be judged in isolation.
• Integrated. Variants rendered inside the project's framework, on a real route with the real header, data and density, because a variant in a vacuum always looks fine. Work on a dedicated prototype/{name} branch that is never merged. Follow the project's conventions (Nuxt: pages/, components/, its CSS system) and name files so they are obviously prototypes: components/prototype/, pages/prototype/{name}.vue. Start it with the project's normal dev command.

Rules

• No polish. No tests, no error handling beyond what makes it run, no abstractions, no generalising for later.
• No persistence. State lives in memory. Persistence is something a prototype checks, not something it depends on.
• Surface the state. After every action or variant switch, show the full relevant state and what just changed.
• Read-only against the real app. Integrated variants never call real mutations. Stub them.

Logic prototype

For "does this state machine / data model / API shape hold up". One HTML file a non-developer can drive.

• Keep the logic in one <script> block as a pure module: a reducer (state, action) => state, an explicit state machine when "which actions are legal now" is part of the question, or a few pure functions over plain data. No DOM inside it. The page calls it, never the reverse.
• Page layout, top to bottom:
  1. Title and the question.
  2. Current state as labelled fields, not raw JSON, re-rendered after every click.
  3. Free-play: one button per action, always available, any order.
  4. Guided scenarios as tabs. Each has a short plain-language description (the situation and what to watch for) and its steps as real buttons that run in order. Starting a scenario resets to a known initial state.
• Scenarios cover what is hard to reason about on paper: the happy path, an awkward edge case, an attempt at something that should be illegal.
• Domain language everywhere. Buttons and labels read like the business, not like the code.
• Clean and restrained: readable typography, generous spacing, one accent colour, no animation.