prototype

# Rapid prototyping ## Usage ```text /prototype plan <name> [area] [feature] /prototype build <name> [area] [feature] /prototype html <name> [area] [feature] /prototype lightweight <name> [area] [feature] /prototype test <name> [area] [feature] /prototype results <name> [area] [feature] ``` Use `workspace/<area>/projects/<feature>/` when area and feature are known. Do not turn a prototype into a production claim; label mocked data, simulated behavior, shortcuts, and untested assumptions. ## Plan Create `prototype-brief.md` with: - hypothesis and user problem; - target participant and scenario; - measurable success and failure signals; - must-have interactions, mocked behavior, and explicit cuts; - time box and decision date; - privacy, accessibility, and data constraints. Choose the cheapest artifact that can answer the question. Prefer a flow or static concept over an app when interactivity is not material. ## Build Select the stack from the validation need and the user's environment. Examples: | Need | Suitable approach | |------|-------------------| | Marketing concept | Static HTML or existing site stack | | Data-rich workflow | React or the product's current framework | | AI interaction | Existing app stack with mocked or sandboxed model calls | | Internal process | Lightweight script, notebook, or low-code tool | | Production-shaped UI | `/prototype-ui` with verified design-system context | Create working files under `prototype/`, document how to run them, and keep mock data obviously synthetic. Reuse the repository's existing stack when working inside a product codebase. ## HTML mode Create `prototype-site/` with accessible, responsive pages and minimal dependencies. Use realistic but synthetic copy. If CDN dependencies are used, disclose that the prototype is not offline-capable. ## Lightweight mode Create `prototype.html` as one self-contained artifact when practical. Inline local CSS and JavaScript, avoid unnecessary frameworks, and keep the file easy to share and delete. Do not claim offline support when any remote asset remains. ## Test Create `prototype-test-plan.md` with scenario-based tasks, pass/fail criteria, observations, and neutral follow-up questions. Cover the core path plus relevant empty, loading, error, permission, and recovery states. For a live URL, use an available browser tool only when authorized. Record the environment, build, viewport, and timestamp so results are reproducible. ## Results Create `prototype-results.md` with: - hypothesis: validated, invalidated, or inconclusive; - participants or test environment; - observed evidence and verbatim quotes; - failed paths and accessibility findings; - known prototype shortcuts; - recommendation: proceed, iterate, pivot, or stop; - engineering and design handoff needs. Keep evidence separate from interpretation and do not generalize beyond the test sample.