Interactive Prototyping

Interactive Prototyping

Production Addendum

Before generating a prototype, read and follow [references/production-pipeline-rules.md](references/production-pipeline-rules.md). These production rules override older default behavior when they conflict.

Key production requirements:

1. Accept multiple product inputs: raw requirement, confirmed requirement analysis, PRD, meeting note, workflow description, existing prototype, or stakeholder feedback.
2. Prefer confirmed requirement analysis or confirmed PRD as input when available, because prototype decisions should trace to reviewed product intent.
3. If shortcutting from raw or unconfirmed input, mark the prototype as a draft and list assumptions, risks, and missing confirmations.
4. The prototype validates workflow, information architecture, page responsibilities, states, and interaction logic; it is not the PRD and not production implementation.
5. Support multiple prototype formats. HTML is the default portable interactive format; Figma is supported when Figma tooling is available; Figma-ready specifications and Markdown/Mermaid wireframes are valid fallbacks.
6. Also produce a natural-language prototype guide, prototype open questions, and a prototype confirmation checklist.
7. Add AI/Agent UI only when AI/Agent classification is AI-enhanced or AI-core and the user has confirmed or accepted that classification.
8. Do not default AI/Agent UI to a standalone primary menu. When AI supports business workflows, place it as a global or module-level right-side collapsible contextual assistant, detail-panel assistant, or inline AI action. Use a standalone AI menu only when AI/Agent is itself the primary product surface.
9. For every primary operation in the MVP path, provide the corresponding interaction surface such as a create/edit form, detail page, drawer, modal, confirmation dialog, permission-denied state, success/error feedback, or pending-approval state.
10. HTML prototypes must be genuinely interactive, not static mockups. Before handoff, verify that scripts load without syntax/runtime errors and smoke-test representative navigation, drawer/modal opening, form actions, state changes, role/theme changes, AI assistant expand/collapse, and success/error feedback. If a check cannot be run, state that explicitly in the guide.
11. Use the user-specified output folder or Prototype/; never overwrite existing files.

Purpose

Create an interactive prototype that helps stakeholders validate product flow before PRD finalization, after PRD review, or before development handoff.

Valid input paths:

Raw requirement -> prototype draft -> confirmation -> requirement analysis / PRD
Confirmed requirement analysis -> prototype -> confirmation -> PRD
Confirmed PRD -> prototype -> interaction confirmation -> development specification
Existing prototype or feedback -> revised prototype -> confirmation

When input is not confirmed, clearly mark missing analysis assumptions and open questions.

Operating rules

1. Treat the prototype as a validation artifact, not the final PRD or production code.
2. Choose the prototype format from the user request and available tools: self-contained HTML by default, Figma when tooling is available, Figma-ready specification when Figma tooling is unavailable, or Markdown/Mermaid for low-fidelity validation.
3. Include realistic but non-sensitive sample data.
4. Cover MVP main path first; do not build a landing page unless requested.
5. Derive page structure from the strongest available source: confirmed PRD, confirmed requirement analysis, then raw requirement.
6. If the source is not confirmed, include assumptions and prototype-specific open questions.
7. Include visible states: empty, loading where relevant, error, permission denied, success, pending confirmation, and edge cases when important.
8. If the product is Traditional, do not add AI UI just because modern products often have AI. Add AI/Agent UI only when the AI/Agent classification is confirmed as AI-enhanced or AI-core.
9. Place AI/Agent UI according to business ownership: use a global right-side collapsible assistant for cross-page support, a module-level right-side assistant for page-specific support, detail-panel assistants for object-specific support, and inline AI actions for narrow tasks such as summarize, draft, classify, explain, or search similar cases. Avoid a standalone AI primary menu unless AI/Agent is the main product surface.
10. For each primary operation button in the MVP path, design enough interaction depth to validate the workflow. Include the relevant create/edit form, detail view, drawer, modal, confirmation step, validation error, permission-denied state, success/error feedback, and pending confirmation or approval state where applicable. Do not leave important actions as decorative buttons only.
11. Treat clickable HTML as executable software: use robust event binding, avoid fragile inline handlers when possible, and verify that every primary button has a working target behavior.
12. Generate companion documents: prototype guide, prototype confirmation checklist, and prototype open questions.
13. Write to the user-specified folder, otherwise Prototype/. Never overwrite existing files.

Frontend style rules

Apply these rules to generated HTML prototypes, Figma-ready specifications, and visual design notes:

1. Do not use blue, purple, or adjacent hues as the dominant palette, large surface color, major background, large card fill, or main navigation color.
2. Use only a small amount of low-saturation blue as an accent for focus, links, status indicators, or one-off highlights when it improves usability.
3. Do not use large gradient backgrounds. Keep backgrounds quiet, mostly solid, and suitable for product review.
4. Do not use border-left as a layout or emphasis pattern.
5. Reflect whitespace as a design material: leave deliberate breathing room, avoid dense decorative panels, and keep hierarchy clear.
6. Support light and dark theme switching when generating HTML prototypes or specifying design behavior.
7. Use 3px border radius for cards, buttons, inputs, tables, modals, and other rounded UI surfaces unless the source product explicitly requires otherwise.
8. Favor neutral, restrained palettes with accessible contrast. Avoid purple-blue gradients and visually loud decorative styling.

When the user asks for visual style that conflicts with these rules, call out the conflict and ask for confirmation before applying it.

Intake

Extract:

| Item | Output | |---|---| | Source type | Raw requirement / confirmed analysis / confirmed PRD / meeting note / existing prototype / feedback | | Confirmation status | Confirmed / pending / shortcut / conflicting | | Target users | Roles and permissions | | MVP main path | User goal and completion signal | | Pages | Required pages and page responsibilities | | Data | Sample data and sensitive fields | | Interaction depth | Static page flow / clickable demo / stateful HTML prototype / Figma prototype / Figma-ready specification / Markdown-Mermaid wireframe | | AI/Agent classification | Traditional / AI-enhanced / AI-core / pending | | Output folder | User-specified or Prototype/ |

Prototype formats

Use this selection rule:

| Requested or best-fit format | Output rule | |---|---| | HTML prototype | Create a self-contained .html file with clickable flows and state simulation. This is the default when the user does not specify a design tool. | | Figma prototype | If Figma tooling is available and the user asks for Figma, use the available Figma tools to create or update the prototype. | | Figma-ready specification | If the user asks for Figma but no Figma tool is available, output a detailed specification covering pages, frames, components, variants, states, interactions, naming, layout guidance, and handoff notes. | | Markdown / Mermaid wireframe | Use for early low-fidelity validation, workflow maps, page-state tables, or when a clickable prototype is not required. | | Existing prototype revision | Use HTML/Figma/screenshots/feedback as input and output revision notes plus updated prototype artifacts or specifications. |

Prototype output

Default files:

02-interactive-prototype.html
02-prototype-guide.md
02-prototype-confirmation.md
02-prototype-open-questions.md

Any prototype format should define:

1. Page inventory and navigation.
2. Main workflow and completion signal.
3. Key interactions, states, and transitions.
4. Role/permission differences.
5. Empty, error, permission denied, success, and pending-confirmation states where relevant.
6. Sample data and sensitive-data exclusions.
7. AI/Agent UI only when classification requires it.

The HTML prototype, when generated, should include:

1. Main navigation.
2. Core pages from the strongest available source.
3. MVP main flow.
4. Clickable interactions for core actions.
5. Detail panel or modal for important objects.
6. State changes for key actions.
7. Role/permission simulation when relevant.
8. Confirmation dialogs for risky actions.
9. Interaction surfaces for primary operations, including create/edit forms, detail pages or drawers, validation, permission-denied, success/error, and pending-confirmation states.
10. Contextual AI/Agent UI only when classification requires it, preferably as a global or module-level right-side collapsible assistant, detail-panel assistant, or inline AI action rather than a standalone primary menu.
11. Working JavaScript for navigation, drawers, modals, state updates, role/theme simulation, contextual AI assistant behavior, and operation feedback. Generated HTML must not be a static page with inert buttons.
12. A basic interaction smoke-test note in the guide listing which controls were checked.
13. Sample data aligned to scenarios.

Prototype guide

Write for non-technical reviewers:

• What this prototype is meant to validate.
• What source material it used and whether that source is confirmed.
• What is included and excluded.
• How to walk through the main scenario.
• Which interactions are clickable.
• Which content is sample data.
• What users must confirm before PRD or development.

Prototype confirmation checklist

Use this format:

| Item | Confirmation question | Owner | Status | Impact if not confirmed | |---|---|---|---|---| | Source | Is the input document or requirement approved as prototype basis? | Product/business | Pending | Prototype may validate the wrong scope | | Page structure | Are these the right pages and navigation? | Product/business | Pending | PRD page scope may be wrong | | Main flow | Does the MVP main path match real work? | Business user | Pending | Functional requirements may be wrong | | Data fields | Are key fields sufficient and correctly named? | Product/tech | Pending | Data model and API may change | | Permissions | Are role views and restricted actions correct? | Business/admin | Pending | Security model may change | | AI/Agent | Is AI/Agent really in scope? | Product/tech | Pending | PRD AI sections may be added or removed |

Handoff

For PRD work, pass forward:

• Source document and confirmation status.
• Confirmed prototype artifact or prototype guide.
• Prototype confirmation checklist.
• Remaining open questions.

For development specification work, pass forward:

• Confirmed PRD when available.
• Confirmed prototype artifact, Figma-ready specification, or interaction guide.
• UI state, permission, and exception notes.
• Remaining interaction questions that may block implementation.

If the prototype is not confirmed, downstream PRD or development documents may still be drafted but must be marked as based on unconfirmed prototype assumptions.

Self-check

• [ ] name frontmatter matches the folder name: interactive-prototyping.
• [ ] Prototype validates workflow, not just visual layout.
• [ ] MVP path is clickable or clearly represented in the selected prototype format.
• [ ] Source type and confirmation status are explicit.
• [ ] It does not add AI UI unless AI classification supports it.
• [ ] AI/Agent UI is placed in the relevant business workflow as a contextual assistant or inline action unless AI/Agent is the primary product surface.
• [ ] Primary operation buttons have corresponding forms, detail surfaces, confirmation states, permission states, and success/error feedback where needed.
• [ ] HTML prototype scripts have been syntax-checked and representative buttons have been smoke-tested; primary buttons are not inert static controls.
• [ ] Prototype guide is understandable by non-technical stakeholders.
• [ ] Confirmation checklist states what must be reviewed before PRD or development.
• [ ] Output files are placed in the requested folder or Prototype/ without overwriting.
• [ ] If Figma was requested, the output either uses available Figma tooling or explicitly provides a Figma-ready specification fallback.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Lucky2024-pllove
• Source: Lucky2024-pllove/product-to-delivery-lifecycle-skills
• License: MIT

Install and usage instructions live in the source repository linked above.