Prd Write

PRD Write

Core Rule

Run the workflow in this order:

1. Inventory source materials and mark the single write target; treat all other Feishu links as read-only references.
2. Clarify requirements with Superpowers using-superpowers + brainstorming, or a local brainstorming pass if Superpowers is unavailable.
3. Produce a requirement brief and get alignment before design-heavy work.
4. Create a page/state inventory before image generation so visual work does not invent workflow coverage.
5. Generate a first-pass visual prototype with imagegen from the clarified product description.
6. Build, read, or refine an interactive HTML demo based on that visual prototype to validate real interactions.
7. Verify the demo flow, capture key screens, and optionally redraw them with imagegen for a cleaner PRD presentation.
8. Prepare business artifacts: flowchart, status machine, roles/permissions, fields/data dependencies, analytics, and acceptance checks.
9. Write the PRD with the user's PRD template, self-check it, then update only the explicitly targeted document.

Do not jump straight into PRD writing when the product path is still blurry.

Writing Style: Direct And Concise

Keep the original PRD structure and requirement coverage, but write only information that changes product understanding, implementation, testing, or decision-making.

• Start sections with the business fact or requirement. Do not narrate how the document is organized, how readers should review it, or why a screenshot is placed there.
• Omit meta prose such as “本 PRD 以 HTML 原型为依据”“文档先放完整页面总览”“便于评审确认页面结构” when the attachment, screenshot, caption, and following requirement already make that relationship obvious.
• Do not announce the next section, summarize the previous section, or explain that a table/screenshot “用于说明” content that is already visible.
• Prefer one direct sentence over a setup paragraph. Example: use “PC 端交互以随附 HTML 原型为准。” only when the source-of-truth relationship must be explicit; otherwise omit it.
• Avoid stiff template language such as “对应需求如下”“用户可通过该功能实现”“系统将会进行”. Use direct product language: “支持…”, “点击后…”, “校验失败时…”.
• After drafting, delete any sentence whose removal does not change scope, rule, interaction, data, exception, or acceptance meaning.

Workflow

0. Source Inventory And Target Safety

Before brainstorming or editing, list the available inputs and classify each item.

• Target document: the one document/wiki/page that may be modified.
• Read-only references: Feishu docs, PRD examples, flowcharts, meeting notes, screenshots, HTML demos, data tables, API docs, or prior drafts.
• Prototype assets: current HTML files, screenshots, imagegen drafts, redrawn images, and generated artifacts.
• External systems: CRM, payment, inventory, approval, messaging, data warehouse, or manual operations.
• Constraints: deadline, platform, brand/design system, compliance, money/data risk, and permission boundaries.

If there is any ambiguity about which Feishu document may be edited, stop and ask before writeback.

1. Requirement Brainstorming

If Superpowers is installed, first use using-superpowers, then use brainstorming for requirement clarification and prototype design. If those skills are unavailable, run a compact brainstorming pass yourself.

Use MECE when asking questions:

• Organize unknowns into non-overlapping domains: business goal and success, users and permissions, scope and non-goals, end-to-end process and states, business rules and calculations, data/interfaces and source of truth, exceptions/non-functional risks, and delivery/acceptance.
• Assign each question to exactly one domain. Do not ask the same decision again with different wording in another domain.
• Within a question, choices must be mutually exclusive and collectively cover the plausible decision space. Include “不涉及/保持现状” or “暂不确定” when either is a legitimate outcome; use free-form follow-up only when fixed choices cannot cover the answer.
• Ask only about information not already established by source materials or earlier answers. Keep a compact domain checklist of confirmed / not involved / open so no domain is accidentally skipped.
• Ask one decision at a time unless two facts are inseparable. Finish blocking questions first; non-blocking details may be recorded as assumptions.

Clarify these points before writing:

• Business background and why this change matters now.
• Primary users, secondary users, operators, reviewers, admins, and external systems.
• Platform type: mini-program, app, PC web, admin backend, or mixed.
• Existing inputs: Feishu docs, PRD drafts, HTML demos, screenshots, data tables, API docs, meeting notes.
• Final target: local document, Feishu doc/wiki, or a new artifact.
• Product scope: in scope, out of scope, and explicit non-goals.
• Main success path and important exception paths.
• Permissions, state changes, money/data/compliance risks, and audit needs.
• Menu and core behavior tracking. Identify menu exposure/click and core action events, define PV and UV counting requirements, and map each event to the required analytics table fields: 埋点ID, 事件名（event_name）, 事件名, 端, 模块/页面, 触发时机, 角色, 属性清单, 属性说明, and 状态.
• Open questions that block implementation versus details that can be assumed.

Output a short requirement brief before visual or HTML work:

• One-sentence product intent.
• Business goal and success signal.
• Users/roles and permission boundaries.
• In scope, out of scope, and explicit non-goals.
• Main success path and important exception paths.
• Tracking scope: menus and core behaviors that must record PV and UV, with preliminary event_name, platform, module/page, trigger timing, role, properties, property descriptions, and lifecycle status.
• Key assumptions and open questions.
• Proposed next artifact: image prototype, HTML demo, PRD outline, or Feishu writeback.

When the user already gives enough context, summarize assumptions and proceed, but still keep the brief as the source of truth.

2. Page And State Inventory

Create a screen/module inventory before image generation or HTML work.

For each page or module, capture:

• Platform and layout type: mini-program/app two-column PRD layout, PC vertical PRD layout, backend/admin, or mixed.
• Entry condition and actor.
• Primary user decision or action.
• Required displayed fields and data source.
• Actions, validation, and next state.
• Empty, loading, disabled, expired, failed, and permission-denied states.
• Related tracking events, explicitly distinguishing menu tracking and core behavior tracking, with PV/UV requirements and the required analytics table fields.

For workflows driven by task/order/payment/approval status, create a status table before writing page details:

3. First-Pass Visual Prototype

After the requirement brief and page/state inventory, use imagegen to create a first-pass static prototype from the clarified product description. If imagegen is unavailable, stop and tell the user instead of silently substituting another generator.

Use this node to:

• Turn rough user language into concrete page composition, hierarchy, and visual direction.
• Explore key screens before spending time on interactive HTML.
• Align with the user on product feel, information density, and workflow coverage.

Rules:

• Generate only screens that are needed to understand the main workflow and major exceptions.
• Keep output close to the clarified requirement; do not invent unapproved business logic.
• Label unresolved areas as assumptions in discussion, not as final PRD facts.
• Treat this visual prototype as a design draft, not as source-of-truth interaction logic.

4. Interactive HTML Demo

Build, read, or refine an interactive HTML demo before writing the PRD.

When the requirement covers both PC and APP:

• Create two independent, self-contained HTML files: one PC prototype and one APP prototype.

• The PC HTML contains only PC pages, navigation, states, and interactions. The APP HTML contains only APP pages, states, and interactions.

• Do not embed APP screens or APP walkthrough content inside the PC HTML, and do not place APP content above the PC prototype as part of one combined file.

• Validate and capture the two prototypes separately. Maintain separate PC and APP screen inventories even when both implement the same business rule.

• In the Feishu PRD prototype attachment area, use a two-column layout: PC title, attachment, and short description in the left column; APP title, attachment, and short description in the right column.

• Both columns must contain real uploaded HTML attachment blocks, not filenames, placeholders, raw links, or a single combined attachment.

• Base the HTML demo on the approved first-pass visual prototype.

• For an existing HTML prototype, inspect the DOM, screens, state variables, event handlers, and navigation paths.

• For screenshots, map every screenshot to a page state and interaction step.

• For a new prototype request, create a concise demo that exposes the real workflow, not a marketing page.

• Add enough interaction to validate navigation, branching, state transitions, and major exception paths.

• Capture key screens for the PRD. Prefer actual prototype screenshots when available.

• List screen inventory, user actions, state transitions, empty/error states, and backend dependencies.

Validate the demo with a compact interaction matrix:

5. PRD Screenshot Redraw

Before final Feishu writeback, decide whether the prototype screenshots should be redrawn.

Use imagegen when:

• The prototype screenshot is visually rough but the interaction is already clear.
• The PRD needs cleaner, more consistent app/mini-program/PC visuals.
• The user explicitly asks to redraw, beautify, or normalize prototype screenshots.

Rules:

• Preserve the original interaction, fields, wording, page state, and information hierarchy.
• Do not invent new features, controls, metrics, states, or business rules during redraw.
• Keep a mapping from original screenshot to redrawn image so the PRD remains traceable.
• If both are useful, keep original screenshots for validation and use redrawn images in the PRD.
• Label redrawn assets clearly in filenames or captions when they are not direct screenshots.

Read references/page-description-layout.md for how first-pass visuals, HTML screenshots, and redrawn PRD images should be placed or tracked.

6. Business Artifacts

Create the business artifacts before or during PRD writing.

• Requirement size: classify the request before creating artifacts. Small means a localized change with at most two user-visible pages/states, one main actor path, and no meaningful cross-system or multi-source aggregation. Medium means three to six pages/states, multiple roles or branches, or one cross-system/multi-source dependency. Large means seven or more pages/states, multiple systems/roles, substantial state lifecycle, allocation/calculation, financial/data risk, or several cross-cutting dependencies. When signals conflict, use the larger size.

• Business architecture diagram: mandatory for every medium or large requirement; optional for small requirements. It is separate from the business flowchart and cannot be replaced by one. Show the stable structure of the solution: input/data sources or upstream channels, rule/calculation/import paths, merge or aggregation logic, core management/capability layer, downstream allocation/application/query/audit outputs, and the important ownership or bypass boundaries. Use the user's business terms and show formulas or composition relationships when they define the architecture.

• Architecture diagram quality: follow the visual grammar of the provided reference—group parallel sources into clearly bounded regions, use directional connectors into merge/summary layers, distinguish core results from downstream views, and label exceptional bypass paths. Do not produce a generic technical stack diagram unless the requirement is actually about infrastructure.

• Feishu architecture diagrams must be inserted as a native whiteboard block, not as raw code or an external screenshot. After insertion, export or preview the whiteboard and verify legibility, connector direction, grouping, and that no label is clipped or overlapping.

• Business flowchart: split complex workflows into small scenario-level diagrams instead of one combined mega-flow. Separate by business scenario, product type, actor path, lifecycle stage, page/status transition, or review/approval stage when branches would otherwise mix together. Use the user's actual business terms; do not reuse example labels unless they appear in the source materials.

• Feishu PRD product/business flowcharts must be inserted as Feishu whiteboard blocks, not left as raw Mermaid, PlantUML, SVG source, screenshots, or code blocks. Use Feishu whiteboard-native SVG presentation by default for process maps, status maps, page-flow maps, and approval-heavy diagrams.

• For simple or medium diagrams, create a polished <whiteboard type="svg"> block. For complex diagrams, create a blank whiteboard and use lark-whiteboard to place editable SVG/native nodes. Never leave <pre lang="mermaid">, raw PlantUML, raw SVG text, or image-only screenshots as the final flowchart presentation in Feishu.

• Feishu flowcharts should visually match polished product whiteboards similar to role/status flow maps: title and subtitle at the top, clear phase rows or swimlane bands, rounded cards for steps/pages/statuses, arrow connectors, status colors, small legends, and concise business labels.

• Use blue for primary progression, teal/green for passed/effective states, purple for review/freeze states, red for reject/fail/void states, and orange/yellow for pending/timeout/manual intervention. Avoid dense generic Mermaid styling.

• Feishu process diagrams: prefer SVG whiteboard diagrams over PlantUML for final PRD presentation when the flow is approval-heavy or needs page/status mapping. Keep each diagram to one scenario with one clear start, one clear end, clear swimlanes or phase rows, and only the exception paths needed for that scenario. Avoid nested multi-scenario diagrams that combine unrelated create/close, submit/review, approve/reject, timeout, vacancy, resignation, fallback, or settlement rules in one chart.

• Read references/feishu-whiteboard-flowcharts.md before creating or writing back Feishu PRD flowcharts.

• Roles and permissions matrix: role, entry point, viewable data, allowed action, forbidden action, audit requirement.

• Status machine: status definition, entry condition, trigger action, next status, exception/fallback.

• Field/data dictionary: field name, meaning, source of truth, required/optional, validation, display rule.

• Analytics plan: output the analytics event table with exactly these columns: 埋点ID, 事件名（event_name）, 事件名, 端, 模块/页面, 触发时机, 角色, 属性清单, 属性说明, 状态. Do not use the previous Data设计/字段枚举 block or the old 名称/发起方/动作类型 table. Put PV/UV counting rules, UV deduplication key, and special collection rules in 属性清单 and 属性说明.

Use product language in labels, not implementation jargon.