| name | mock |
| description | Build a throwaway interactive prototype to validate one unresolved interaction or behavior before writing production code. Use when the user explicitly asks to "mock it up first" or "prototype this", or when competing UI behaviors need a disposable hands-on comparison. |
| version | 1.0.0 |
| author | Hien Dinh |
| license | MIT |
Mock Before Wiring
Validate the idea with a disposable prototype. Cheap to throw away, cheap to redo.
Do not touch the real codebase. The prototype lives ONLY in the
session scratchpad directory. No production files created or modified.
Process
- Pin down what's being validated. One sentence: "This mock answers: "
(e.g. "should filtering be inline or a sidebar?"). If you can't write that
sentence, ask the user what's undecided.
- Resolve a disposable location. Prefer a harness-provided scratchpad. If
none exists, create a temporary directory outside the repository. Never use
an untracked directory inside the project as a substitute.
- Non-web target? Scope the mock's authority first. When the product is
native, CLI, or embedded, say up front what an HTML mock can and cannot
answer. It CAN validate flows, layout, copy, and state transitions; it
CANNOT validate platform feel, native gestures, assistive-technology
behavior, or animation physics. If the undecided question is on the
cannot list, say so and validate in the platform's own cheap medium
instead (a throwaway SwiftUI
#Preview, a --dry-run flag, a bench
sketch) — do not fake confidence with a web approximation.
- Build one self-contained HTML file in that directory:
- Inline all CSS/JS — no external requests
- Fake all data with hardcoded fixtures; fake all backend calls with
setTimeout + canned responses
- Make the undecided part interactive; keep everything else minimal
- Preview with the best available capability. Render it with the Artifact
tool when available. If this agent has no Artifact tool, provide the absolute
file path and, when supported, open it in a local browser. Do not claim it was
previewed when the environment cannot render or open it.
- Iterate. Apply requested changes to the same file. Refresh the existing
preview when supported; otherwise provide the unchanged file path.
- Exit. When the user is satisfied, ask: "Does this match what you wanted?"
Then extract the confirmed decisions into a short spec in conversation:
## Decisions validated by mock
- <decision 1>
- <decision 2>
## Explicitly rejected
- <alternative that was tried and declined>
The spec — not the prototype code — is the input to real implementation.
Never copy prototype code into the codebase.
