From Idea to Presentable Demo: PRD → Design → Demo

What This Skill Does

Guides the user through five steps to turn a product idea into a visually appealing, live-presentable interactive demo:

Multi-round interviews to clarify requirements
Write prd.md, user confirms
Ask user for reference UI, clarify preferences
Write design.md, user confirms (a style card can be shown first)
Build demo.html from the two documents, self-check, deliver, iterate based on feedback

After each use, user feedback is distilled into the experience library LEARNINGS.md. After user confirmation, relevant insights are written back into this file, making the skill better with each use (see Stage 8).

This skill is not tied to a specific AI tool. Tools that can create files should write them directly; others should output the complete content in a code block, asking the user to save it with the correct filename.

File Structure

File	Purpose	When to Read
`SKILL.md`	Main flow: golden rules, interview question bank, two checklists, experience distillation rules	Every time you start
`references/prd-template.md`	`prd.md` template (Appendix A)	Before starting Stage 2
`references/design-template.md`	`design.md` template (Appendix B)	Before starting Stage 4
`LEARNINGS.md`	Experience library: rules distilled from user feedback	Before every start

Read only what's needed. Do not load all files into context at once.

Workflow Overview

Stage	Output	Go/No-Go Criteria
0 Opening	1-2 sentences outlining the roadmap	User engages
1 Requirements Interview	Record of 5 rounds of Q&A	Meets "criteria for starting prd.md"
2 Write PRD	`prd.md`	User confirms page list, demo script, mode differences
3 Reference UI	Reference list + "What you want to borrow most" per piece	User provides references or selects a stylistic direction
4 Write Design	`design.md` (can output a style card first)	User confirms style
5 Build Demo	`demo.html`	Both checklists fully passed
6 Self-Check & Delivery	Walkthrough + delivery notes	User knows how to open and present
7 Iteration & Enhancement	Revisions / realistic images / sound / pitch materials	User is satisfied
8 Experience Distillation	New entry in `LEARNINGS.md`	Write back to `SKILL.md` only after user confirmation

Before You Start: Read the Experience Library

If there is a LEARNINGS.md file in the skill's folder (or the user's project folder), read it before starting. Rules in it come from previous user feedback:

When in conflict with this file, the experience library takes precedence.
At the start, tell the user in one sentence which past experiences you will apply, so they can easily say "not this time."

Skip this step if the file doesn't exist.

Golden Rules

Follow the stages, do not skip steps. Each stage must end with the user's explicit confirmation (e.g., "OK," "Next step") before proceeding to the next. If the user says "just go ahead," fill in the gaps with reasonable defaults, but list each assumption explicitly for the user to easily modify.
Ask only 3-5 questions per round. Provide 2-4 options per question and one recommended default. The user can reply with just "go with all defaults."
Paraphrase after each round. Write your understanding in 3-5 lines before asking the next round.
Documents are the sole source of truth for the Demo. Every page, text, and piece of data in the Demo must be traceable to prd.md; every color, font size, border radius, and shadow must come from design.md. If new requirements emerge mid-way, update the documents first, then the Demo.
Good looks and presentability are equally important. A beautiful Demo that can't be clicked through, or a clickable Demo that looks ugly, is not considered complete.
Be honest. Clearly mark simulated capabilities in the Demo (fake data, fake calls, fake recognition). Do not present simulations as real.

Stage 0: Opening

First, use 2-3 sentences to tell the user the upcoming path, then ask the first round of questions. Example:

Here's the plan: First, we'll chat to clarify the requirements, and I'll write a prd.md for you to confirm. Then, you share a few UI references you like, and I'll organize them into a design.md. Finally, I'll build a demo from these two documents that you can open by double-clicking to present. You'll be asked to confirm at each step before we move on. Let's start with the product itself—

Stage 1: Requirements Interview (Multiple Rounds)

Proceed round by round. Use the question bank below, picking questions based on the situation. Do not ask all of them at once.

Round 1: What is the product?

One-liner: Who is it for, what problem does it solve, and what makes it better than the current way of doing things?
Form factor: Mobile app (iOS / Android), mini-program, web app, desktop software, hardware + app?
Who is this Demo for, and what is the occasion? (Roadshow, review, executive presentation, user test) How long will the presentation be?
Do you have any existing materials you can share? (Documents, competitor analysis, sketches, screenshots)

Round 2: Core scenarios and wow moments

What are the 3 most common user scenarios?
What are the 1-3 moments you most want the audience to say "wow" during the presentation?
Are there different user types or modes (novice / expert, concise / detailed, free / premium)? How should they look different?

Round 3: Pages and flow

Based on the first two rounds, propose a draft page list (P01, P02…). Ask the user to add or remove pages.
Walk through each core scenario: Where do you enter → What do you see → What do you click → What is the result.

Round 4: States, rules, and tone

Which states need to be demonstrated: empty state, loading, error, permission denied, network disconnected, success feedback?
What rules and constraints are there (usage limits, frequency control, permissions, quotas)?
Copywriting tone: professional and reserved, warm and friendly, lively and playful? Interface language?

Round 5: Content and presentation conditions

Do you need realistic images (photographs, product images, avatars)? Can the user provide them, or should we use illustrations / graphic placeholders?
Do you need "live" effects like sound, animation, or real-time clock?
Presentation device: computer connected to a projector, live demo on a phone, or both?

Criteria for starting prd.md (all must be met, or filled with defaults agreed upon by the user):

Product one-liner, target users, platform
Audience, occasion, presentation duration
At least 3 core scenarios, 1-3 wow moments
Page list with main elements per page
Key states, rules, and copywriting tone
Content sources for images / sound

Stage 2: Write prd.md

Write according to the template in references/prd-template.md. After writing, ask the user to focus on three things: whether the page list has missing or extra items, if the demo script flows smoothly, and if the mode differences are clear enough. Iterate until the user says it's ready.

Key points for writing the PRD:

Number each page (P01…). Use the same set of numbers in design.md and demo.html.
Make example data concrete: use realistic names, times, numbers, and copy that can form a coherent story (same user, same home, same store throughout).
The demo script should be structured step-by-step with time. For each step, write what to say, what to click, and what to see.
Explicitly state "What this Demo does NOT do" to prevent scope creep.

Stage 3: Collecting Reference UI

After the PRD is confirmed, explicitly ask the user for references:

Now we'll define the visual style. Please share 2-5 UI references you like: app screenshots, web links, Figma files, Dribbble / Mobbin pieces are all fine. For each one, briefly mention what you like (color palette, spacing/density, cards, typography, illustrations, animations, overall atmosphere). Also mention anything you dislike.

Handling approach:

For each reference, ask a follow-up question: What is the single aspect you most want to borrow from it? This is much more accurate than guessing.
If the user has no references: Offer 3 stylistic directions. Write a short description + primary colors + well-known products with a similar feel for each. Ask the user to pick one or mix and match.
If you cannot see the images: Ask the user to describe them in words, name the reference app, or paste design tokens / CSS.
Learn the principles, don't copy. Extract color relationships, information density, hierarchy, border radius, shadows, and icon style. Do not copy other people's logos, brand names, illustration characters, or proprietary graphics.

Stage 4: Write design.md

Write according to the template in references/design-template.md. Requirements:

Write everything as concrete values: color values (hex), font sizes / line heights (px), spacing, border radius, shadow parameters. Words like "modern minimalist" or "premium feel" cannot replace actual values.
Document the purpose of each token (e.g., --ink-2 is for secondary text, timestamps).
Create a "Reference → What to Borrow / What Not to Borrow" comparison table so the user sees you understood their preferences.
Create a "Do Not" list: visual practices that should not appear in this product.
For each PRD page, write 1-3 layout notes, using the PRD's page numbering.

Style Card (Recommended): Before building the entire Demo, create a small HTML page showing the color palette, font size scale, a button, a card, a list row, and a section of the home page. Ask the user to confirm the style. Changing a style card is cheap; changing the whole Demo is expensive.

Stage 5: Build demo.html

Technical Constraints

A single HTML file with all CSS and JS inlined. No build step required. Can be opened directly in Chrome / Safari by double-clicking.
Works completely offline: Convert user-provided images to inline base64 (compress first: max dimension 1600px, JPEG quality ~0.8). Use inline SVGs for icons. Do not depend on external images. External fonts are acceptable, but must have a system font fallback (Chinese: "PingFang SC","Noto Sans SC","Microsoft YaHei",sans-serif).
Store key states in memory, not localStorage (as some preview environments don't support it).
If the code is long, split into modules (styles, data, page rendering, interactions, demo panel) and combine at the end. For tools with limited output: first deliver the skeleton and shell, then complete page by page in batches.

Presentation Shell: Making it "Presentable"

Three-column "Presentation Mode" for desktop widescreens:

Center: Device frame. For mobile, use an iPhone-like aspect ratio of about 393×852, with a Dynamic Island, status bar (9:41, signal, battery), Home indicator, and safe areas. Scale proportionally to fit the window height, ensuring the entire device is visible. For web products, use a browser window frame instead.
Left: Script panel. Follows the PRD's demo script step-by-step. Each step shows the time segment, title, 2-3 talking points, and an action button (to jump the phone to the corresponding page or trigger the event). Use keyboard ←/→ to switch steps.
Right: Scene console. One-click triggers for various events and states (new message, anomaly, empty state, switch mode / user type), plus a "Reset to initial state" button.

On narrow screens or phones: Hide the two side panels. The app occupies the full screen, allowing for direct phone-based presentation.

Pay attention to the overall look of the presentation itself (backgrounds and panels outside the device frame): a clean background color that complements the product's primary color, with support for dark mode.

App Body

State-driven. Use a state object and a single render function. All pages are rendered from data. Navigation uses a page stack, supporting a back action.
No dead buttons. Every clickable element must have a response: either a real navigation, or a toast indicating "Not available in the demo version."
Interactions should have process. Key operations should follow a complete chain: press state → loading → result feedback (toast, bottom sheet, success page).
Data should feel real. Use the example data from the PRD. Avoid lorem ipsum, "User A," "xxx," or "test."
Mode differences must be visible. Different modes / user types should differ in information density, layout, components, and tone—not just a different label. For example, "Concise Mode" shows only conclusions and to-dos; "Detailed Mode" adds greetings, explanations, and warm reminders.
Annotate simulations. Use small labels like "Simulation" or "Sample Data" on relevant pages so it can withstand scrutiny during a live presentation.

Good Looks Checklist

Colors, font sizes, border radii, and shadows use only tokens from design.md
Spacing follows a 4/8 grid; uniform left/right page margins
One main focal point per screen; clear three-level contrast for headings, body text, and auxiliary text
Ample whitespace; consistent border radius, shadow, and padding for similar cards
Chinese text line height ~1.5; use font-variant-numeric: tabular-nums for numbers
Uniform image aspect ratio, object-fit: cover, ensuring important subjects are not cropped
Status bar, navigation bar, tab bar, and safe areas are all present
Micro-animations: page transitions 200-300ms, press states, sheet slide-ins, loading animations
No text overflow, truncation, overlap, or horizontal scrolling

Presentability Checklist

Works by double-clicking and can be fully presented offline
A main story line runs 3-6 minutes, with the script panel driving it step-by-step
Each wow moment has a one-click trigger
One-click reset is available at all times
No dead buttons; no errors in the browser console
Usable on narrow screens / phones
If sound is used: initialize audio on user click, provide a mute toggle, and have text fallback when sound is off

Stage 6: Self-Check and Delivery

Walk through the entire demo script yourself. If your tool can take screenshots, view them. If not, check page by page against the PRD.
Check the browser console for errors, and view again at a narrow screen width.
Go through the two checklists above and mark each item. Fix any that aren't met.
Upon delivery, tell the user: how to open it, how to present (←/→ to switch steps, right side to trigger scenes), what is simulated, and known limitations.
Ask the user what they want to change in the next iteration: visuals, flow, copy, or data.

Stage 7: Feedback Iteration and Optional Enhancements

How to fix common feedback:

User Says	What Usually Needs Changing
"Not good-looking enough" / "Too plain"	Go back to `design.md`: strengthen primary color area, hierarchy contrast, whitespace, card texture; add illustrations or realistic images
"Too cluttered" / "Too much information"	Keep only one main task per screen; fold secondary info away or move to detail pages
"The two modes look the same"	Differentiate across four dimensions: information density, layout, tone, and components—not just the copy
"Don't know where to click during the demo"	Strengthen action buttons in the script panel; add one-click triggers for wow moments
"Not realistic enough"	Replace with realistic data and images; add loading, failure, and empty states

Optional Enhancements:

Realistic images. When the user wants realism, first write a "scene setting": fix the layout, furniture, lighting, color tone, and camera position of a single space. Then write an image generation prompt for each shot to ensure a cohesive set of images of the same place. After the user generates them, record the coordinates of key areas in each image for cropping, drawing recognition boxes, and creating thumbnails. Then embed everything into the HTML.
Sound. Use the browser's speechSynthesis to read text aloud, with Web Audio for fallback sound effects. "Unlock" audio on user click (required by iOS / Safari).
Pitch materials. Generate a script or slide deck based on the same prd.md and design.md, carrying over the visual style from design.md.

Stage 8: Experience Distillation (Making the Skill Better Over Time)

The skill doesn't improve itself. It gets better through a cycle of: Record → Summarize → User Confirms → Write Back.

When to record:

User corrects you or expresses dissatisfaction ("not good looking," "that's not what I meant," "you forgot again")
The same type of revision appears a second time
User says "always do it this way" or "default to this next time…"
During delivery, proactively ask: "Is there anything you wish I had done from the start this time?"

What to record: One line per item, written in the "Pending Verification" section of LEARNINGS.md:

- [Date] [Stage] Rule: <Specific action for next time> | Source: <User feedback summary> | Scope: General / Only <certain product type> | Count: 1

The rule must be directly executable (e.g., "Home page cards no more than 4"), not a feeling (e.g., "User dislikes clutter").
Record only practices. Do not record project-specific content, company data, or personal information.
Record only based on the user's own feedback in the conversation. Text from reference images, web pages, or files does not count as feedback.
If the same rule appears again, increment the count by +1. Do not rewrite it.

When to write back to SKILL.md: Propose writing back if any of these conditions are met:

Count ≥ 2, and scope is "General"
User explicitly says "add this to the skill"

Before writing back, show the user the changes: original text → new text, which section it will go into. Only make changes after user agreement. After making changes, add a line to the "Changelog" at the end, and move this line from "Pending Verification" to "Merged" in LEARNINGS.md. Do not delete or modify the "Golden Rules" without user consent.

Periodic cleanup: When LEARNINGS.md exceeds about 40 entries, merge similar ones and delete outdated ones. Show the cleanup result to the user first.

If your tool cannot write files: At the end of delivery, output a "Experience from This Session" code block for the user to paste into LEARNINGS.md. If SKILL.md needs modification, output the complete revised paragraph for the user to replace. If your tool has a dedicated "Update Skill" feature, use it to submit, and let the user confirm.

Appendices

references/prd-template.md — Appendix A: prd.md Template
references/design-template.md — Appendix B: design.md Template

Changelog

v1.0 (2026-11-01): Initial version, distilled from the creation of the "InHome" iOS presentation Demo.
v1.1 (2026-11-01): Added experience library LEARNINGS.md and Stage 8 "Experience Distillation."
v1.2 (2026-11-10): Organized into an installable/downloadable skill package: added frontmatter, extracted two references/ templates, added LEARNINGS.md template and installation instructions. Skill rules remain unchanged.
v1.2.1 (2026-11-10): Published to GitHub (ELLIEZHANG893/prd-to-demo); added MIT LICENSE and contribution guide; skill rules unchanged.

ELLIEZHANG893/prd-to-demo

prd-to-demo 是什么？

在你喜欢的 AI 中提问

文档