PRD and Interactive Prototype Generation

Problem It Solves

Turning a rough product request into reviewable documentation and a clickable prototype often fails in two ways: the PRD style does not match project scale, and the prototype only shows default states. This skill puts requirement clarification, documentation, and frontend prototype constraints into one workflow.

How It Works and Limits

• Clarification: It first checks product type, target users, and the core problem; when unclear, it asks at most 2-3 key questions.
• PRD output: It chooses a traditional full PRD or agile lightweight PRD, reads the template and writing guide, then outputs PRD-[product]-[date].md with measurable goals, P0/P1/P2 priorities, and edge cases.
• Interactive prototype: After reading the prototype guide, it generates a single HTML file using CSS variables and vanilla JavaScript; mobile views use 375px, admin dashboards target at least 1200px, and pages cover loading, empty, error, and confirmation states.
• Iteration: It prefers incremental edits to existing files rather than rewriting the entire HTML; regeneration is reserved for major product or tech-stack changes.

It fits early scoping, review prep, and quick alignment for product, engineering, and operations. It is not a substitute for a full design system, backend API implementation, or high-fidelity visual design.