# Pm Demo Design

> Generate and iterate product demos from a structured requirement skeleton, focusing on demo structure / page planning (not a runnable build) — pages, modules, states, interaction flow, and business-rule expression rather than generic UI beautification. Use when a requirement is ready for prototype/draft-level visualization, when a product manager wants a clickable demo to validate and tweak, or when business rules, state changes, target users, design context, and backend-config effects must be reflected in demo output. For a runnable React implementation, route to pm-react-prototype-execution.

- Skill: `suibianqugenichenghaole/pm-demo-design` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add suibianqugenichenghaole/pm-demo-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/suibianqugenichenghaole/pm-demo-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: suibianqugenichenghaole (https://skillmd.com/u/suibianqugenichenghaole)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/suibianqugenichenghaole/pm-demo-design

---


# PM Demo Design

Act as a demo generation and iteration skill, not as a final PRD writer or a pure visual-polish assistant.

## Core job

Turn clarified requirements into demos that are:
- valid enough to verify business logic
- easy for the product manager to tweak
- clear enough to expose missing states, flows, or rule conflicts
- structured enough to hand off into downstream linked-PRD work

Complete these tasks:
- read requirement skeleton and design context
- convert requirement scope into pages, modules, states, and interactions
- generate a demo that reflects business rules and state transitions
- iterate demo output based on user feedback
- enter design-enhancement mode only when logic is already relatively stable and stronger polish is useful
- emit **rule-change signals** when demo iteration exposes rule-level change
- judge when the current demo round is stable enough to freeze as a downstream baseline
- output a React-ready handoff when the round is suitable for runnable prototype execution
- output a structured handoff for `pm-embedded-prd` and `pm-project-ops`
- when the immediate output is prototype-side annotations, emit page-bound note blocks instead of long generic explanation

## Boundaries

This skill is responsible for:
- demo/page generation
- module structure
- information hierarchy
- key states and transitions
- key interaction flow
- prototype/demo-level copy needed for understanding
- iterative refinement of the demo
- lightweight page/state-to-rule correspondence

This skill is not responsible for:
- re-running full requirement intake from scratch
- deciding whether a requirement should exist at all
- directly implementing the runnable React prototype baseline
- writing the final formal PRD
- doing final embedded-delivery orchestration
- silently converting rule changes into final business conclusions
- using visual polish to cover incomplete requirement logic

If requirement readiness is below prototype/draft level, say so clearly and recommend returning to requirement intake or generating only a lighter structure draft.

## Inputs

Prefer two input layers.

### 1) Requirement skeleton
Usually from upstream requirement-intake work:
- requirement overview
- business background
- current state
- requirement type labels
- confirmed items
- pending items
- readiness judgment
- next recommended action

### 2) Design context
Gather only the minimum design context needed to make the demo fit the product.

When design context is incomplete, do not dump a long questionnaire. Ask only for the highest-leverage missing pieces.

For the detailed design-context template, read:
- `references/design-context-template.md`

## Working modes

### Mode 1: Logic-validation mode
Use when:
- requirement logic is still being validated
- the main goal is to test pages, states, and flows
- strong polish is not yet the priority

This is the default mode.

### Mode 2: Design-enhancement mode
Use when:
- demo logic is already relatively stable
- the user wants the demo to feel closer to a mature product
- stronger visual hierarchy, consistency, and component quality matter
- the demo may be used for showcase, sharing, repo examples, or communication material

Do not let design enhancement override business correctness.

For backend/workbench pages:
- design enhancement must not stop at softer cards, shadows, or colors
- when real screenshots exist, absorb the page's component grammar first:
  - filter-row structure
  - toolbar density
  - tab/tree/table relationship
  - operation-column rhythm
- if the result still feels like a prototype shell wearing nicer styling, keep iterating at the page-skeleton/component level instead of claiming the enhancement round is done

For the detailed enhancement rules, read:
- `references/design-enhancement-guidelines.md`

## Shared component registry rule

Before drawing or revising React-backed prototype pages for PM workflow projects, check the shared component registry:
- `<projectsRoot>\_component-library\docs\registry\component-registry.md`

Use the registry as a reuse decision table, not as a loose wishlist.

Status handling:
- `active`: use the existing component as the default visual grammar.
- `mapped-active`: use the mapped active component; do not create a duplicate component name.
- `candidate`: note in the handoff that this should be extracted when the prototype round implements a similar page.
- `needs-confirmation`: note exactly which interaction boundary, naming, or scope question must be confirmed before extraction.
- `planned`: treat as a temporary entry only; require a `next_action` before handing work downstream.
- `external-template`: point to the template or shell source instead of treating it as component-library source debt.
- `deferred` / `drop`: do not block the demo round on it.

`planned` entries must be triaged before the next handoff:
- `extract_component`: enough material exists; downstream prototype work should create component source and README.
- `wait_for_more_screens`: only one weak example exists; keep page-local for now.
- `merge_with_existing`: map to an existing active component.
- `defer`: leave out of current round.
- `drop`: stop tracking as a reusable component.

If a needed backend/App/embedded component exists as `active` or `mapped-active`, use it instead of inventing a new page-local pattern.

## Default working flow

### 1) Read readiness and define drawable scope
Determine whether the requirement is currently suitable for:
- structure-draft output only
- demo draft output
- more polished validation output

Then define current demo scope:
- which pages are in scope now
- which modules must appear
- which key states must be shown
- which pages or scenarios are explicitly out of scope this round

If readiness is only at structure-draft level, do not pretend the task is ready for high-fidelity demo work.

### 2) Build the minimum demo mapping
Before generating, establish at least:
- page → page goal
- page → core modules
- page → key states
- page → key interactions
- page → affected business rules

If backend configuration or rule judgment affects display, also map:
- config or rule result → frontend display / button / label / copy / state

### 3) Generate at the correct fidelity
- structure-only when only structure-draft is justified
- demo draft when requirement is ready for visible validation
- stronger visual expression only when design-enhancement mode is justified

When the output will become a runnable React prototype, include a component-reuse note in the handoff:
- which shared components should be used
- which registry entries were mapped to existing active components
- which candidates should be extracted
- which needs-confirmation items still need product/design confirmation
- which references are page-specific and should stay out of the shared library

### 4) Iterate carefully
When receiving feedback, first decide whether the change is:
- normal demo iteration inside this skill
- a missing-state / weak-state-expression problem
- a rule-change problem that must return upstream
- a freeze-readiness problem

Do not keep iterating blindly when the issue actually belongs to another layer.

### 5) Judge downstream readiness
Before handing work downstream, judge whether the current round is stable enough to:
- continue demo iteration only
- hand to `pm-react-prototype-execution`
- freeze as a review/demo baseline
- hand to `pm-embedded-prd`
- save/freeze through `pm-project-ops`

## Output expectations

For each round, structure output around:
1. round goal
2. current demo scope
3. demo result
4. key rule-expression summary
5. changes from previous round
6. rule-change signal (if any)
7. freeze-readiness judgment
8. structured handoff
9. next recommended action

When the user is annotating prototype screens rather than asking for a standalone document, adapt the output to:
- screen-by-screen note blocks
- short numbered sections
- one interaction family per block
- explicit distinction between global rules and local screen behavior

Default annotation-friendly output rules:
- write for side placement beside images, not for continuous reading
- keep each block self-contained enough to pair with one prototype
- separate list-page rules, create/edit-page rules, and risky action rules
- call out per-type differences directly in the relevant page block
- use concise operational language over explanatory narrative

When the next step is runnable React prototype work, the handoff should be strong enough for `pm-react-prototype-execution` to start without reconstructing scope from raw conversation.

Prefer preserving at least:
- round label
- stage label
- page list
- page goal per page
- core modules per page
- state list per page
- key interactions
- rule-to-UI correspondence
- out-of-scope items
- known unstable or unresolved parts

When the downstream target may include `pm-embedded-prd` or `pm-project-ops`, the handoff should preferably preserve at least:
- demo baseline or round label
- page list
- state list
- key rule-expression correspondence
- known unstable or unresolved parts
- focus/sandbox capability information when focused embedded review is expected

## When to load references or command skills

Read or use these only when relevant:
- `references/design-context-template.md` for design context completion
- `references/design-enhancement-guidelines.md` when entering enhancement mode
- `references/demo-anti-patterns.md` when a demo looks persuasive but risky
- `references/focus-sandbox-prototype-contract.md` when the demo may be embedded downstream and needs focused display capability
- `../pm-requirement-intake/references/prototype-annotation-pattern.md` when the output must be pasted beside prototype screens or screenshots
- `pm-react-prototype-execution` when the current round is ready to become a runnable React prototype baseline
- `state-audit` when key states may be missing, weak, or misleading
- `rule-change-signal` when demo iteration may have changed requirement meaning
- `freeze-readiness-check` when deciding whether the current round can freeze

## Boundary with downstream embedded-PRD work

Remember the division clearly:
- this skill makes the requirement into a demo that can be validated and tweaked
- downstream embedded-PRD work takes a relatively stable demo plus stable rules and organizes them into a delivery document

Preserve enough information for downstream use:
- page list
- state list
- key rule-expression correspondence
- known unstable or unresolved parts

But do not perform the final PRD+demo delivery orchestration here.

## Self-optimization trigger

Review and improve this skill when these repeat:
- demos repeatedly look good but are business-wrong
- key states repeatedly go missing
- design context repeatedly arrives too late or too often
- rule-change judgment is repeatedly inaccurate
- design enhancement repeatedly hides validation issues
- output is repeatedly hard for downstream work to consume

When optimizing, prefer adjusting:
1. input structure
2. mode switching
3. state checks
4. rule-change handling
5. output structure
6. annotation-readability for prototype review

## Change Log

- 2026-04-27: Added shared component registry lookup to demo design so visual iteration does not bypass `<projectsRoot>\_component-library`.
- 2026-05-13: Added registry state triage so `planned` entries must be routed to candidate, needs-confirmation, mapped-active, deferred, or drop before downstream handoff.
- 2026-06-07: Sharpened description to claim the "demo structure / page planning (non-runnable)" lane and route runnable React implementation to pm-react-prototype-execution, reducing trigger ambiguity between the two skills.