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:

• \_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 \_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.

Source & license

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

• Author: suibianqugenichenghaole
• Source: suibianqugenichenghaole/pm-workflow-system
• License: MIT

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