Edison SinaniAI implementation architectBook a call

AI Team Playbook / Rule 5 of 12

A walkable demo before any screen

No user-facing code is written until a clickable prototype of the screens exists and the lead has clicked through every state of it. The developer builds it with an agent, or a product and UX team supplies it in Figma.

September 16, 2026 · About 2 minutes

Contents

The playbook

  1. Overview

Before code

  1. 1Write the constitution first
  2. 2One instruction file, under 200 lines
  3. 3Prose is advice, hooks are enforcement
  4. 4Three gates before any code
  5. 5A walkable demo before any screen

Building

  1. 6One task, one worktree, one pull request
  2. 7Every contract has a file and two tests

Reviewing

  1. 8AI review first, and filtered
  2. 9Human review by risk tier
  3. 10Done means the evidence is in the pull request

Over time

  1. 11Measure five numbers from day one
  2. 12Protect the people who are still learning

Appendix

  1. AInstall checklist
  2. BOther tools, limits and sources
  3. CTightening the process
  4. DRun the agent with no entitlements

Get the kit

Who owns it
The developer builds it with an agent, or the product and UX team supplies it. The lead walks it, with the designer if there is one. Changes go into the prototype, not into a document about it.
In the kit
docs/prototypes/README.mddocs/prototypes/<feature>.jsxdocs/prototypes/<feature>/ (exported states)
Enforced by
The /spec skill stops without a prototype path for user-facing work. Non-negotiable 7 in the constitution.

Why

Agents build the right screen the first time when they have a picture to build toward, and they build it three times when they have a paragraph. No vendor has a name for this practice. It comes from watching it happen.

The prototype also does the job a design review used to do, at a fraction of the cost. The lead clicks through it and asks the verification questions from the design. Anything wrong is fixed in the prototype in minutes, not in the application in days.

How

The prototype is one self-contained file with realistic mock data that lets a person click between states. React with Tailwind classes is the default, because agents produce it quickly and it renders anywhere, even when the application itself is Vue or something else. It is not pixel perfect, not responsive unless the feature is about responsiveness, and not connected to real data.

It lives at docs/prototypes/<feature>.jsx, committed, and it is kept after the feature ships. It is the record of what was agreed. Deleting it deletes the reason the implementation looks the way it does.

Every prototype starts with a header that answers four questions: which screens, what it copies from the existing app, what it deliberately leaves out, and what else it specifies.

/**
 * Design prototype: shipment consistency findings.
 *
 * Screens behind the tab switcher:
 *   1. Inbox: descriptive status labels, pending split, filter captions.
 *   2. Shipment detail: documents left, checklist right on large screens.
 *
 * Mirrors: DocumentDetailView's two-column layout and sticky pane.
 * Deliberately omitted: dark mode, the "Mark verified" button.
 * Not app code. The app is Vue. This is a throwaway design artifact.
 */

When a product or UX team owns the design. A Figma prototype counts, and it is often better than anything the developer would build. Three things change.

  • The agent cannot read a Figma link. Export every state the prototype covers as an image and commit the images under docs/prototypes/<feature>/, with a short README that answers the same four questions. If the team runs the Figma MCP server, the agent can read the file directly, and the export still gets committed.
  • The export is the record, not the link. A Figma file keeps changing after the walkthrough. The committed images are what was agreed on the day, and the design’s Prototype line carries both the link and the export path.
  • The walkthrough includes the designer. Deviations still go into the design’s deviations section, agreed with the designer, so the implementation and the Figma file do not drift apart without anyone noticing.

When the lead says yes, the design’s Prototype line gets the file path and the date. The implementation task then points the agent at the prototype with one instruction: build this screen from this file, use the app’s components where the prototype mirrors them, and add nothing the prototype does not show. Where the built version will differ from the prototype, the design says so in its deviations section.