prototype-ui

# Product UI prototyping ## Usage ```text /prototype-ui plan <feature> [area] /prototype-ui build <feature> [area] /prototype-ui test <feature> [area] /prototype-ui results <feature> [area] ``` This workflow is production-shaped but company-neutral. Discover the target product's actual stack before generating code; never assume package names, entity scopes, feature-flag syntax, routing, or API shapes. Use `workspace/<area>/projects/<feature>/` and read `context/templates/prototype_ui_template.md`. ## Establish product context Verify from the target repository, design-system documentation, or user-provided source: - framework, language, package manager, and build commands; - design-system packages and supported components; - layout, navigation, routing, and entity model; - API client, state-management, and error conventions; - analytics, permissions, feature flags, and localization; - accessibility and responsive requirements. Label unverified conventions and ask only when a wrong choice would materially change the prototype. ## Plan Create `prototype-ui-brief.md` with: - hypothesis and target user; - entry point, page type, and primary task; - verified stack and reference screens; - components and data needed; - mock-versus-real data boundary; - loading, empty, error, permission, and recovery states; - scope cuts and measurable success criteria. ## Build Create the prototype under `prototype/` and follow the verified product conventions. A typical structure is: ```text prototype/ src/ pages/ components/ hooks/ mock/ types/ package.json README.md ``` - Prefer existing components over reimplementing them. - Match real API types when available; otherwise isolate synthetic types under `mock/`. - Make mocked data and simulated mutations visible in the UI or README. - Include keyboard, focus, labeling, contrast, and reduced-motion behavior. - Add the smallest useful run and test commands to the prototype README. - Do not add production dependencies or modify a target repository unless the user asks. ## Test Create `prototype-test-plan.md` with tasks for discoverability, the primary flow, state transitions, recovery, permissions, and at least one accessibility pass. Test at the scopes and viewports the verified product supports. ## Results Create `prototype-results.md` with: - hypothesis result and evidence; - navigation and component findings; - states and accessibility findings; - verified reusable components and remaining gaps; - required APIs, analytics, flags, and migrations; - prototype shortcuts that cannot ship; - recommendation and next decision. Do not call the prototype production-ready without product-repository integration, tests, security review, and release evidence.