Meeting Figma PRD

Overview

Convert meeting-note originals and Figma source material into a structured Markdown PRD. Extract facts from the meeting text when available; when recordings or notes are missing or incomplete, use Figma page structure, UI copy, frames, components, states, annotations, and prototype flows to complete the requirement draft. Export corresponding screenshots, associate design evidence with requirements, and write function descriptions as professional product manager PRD tables while clearly marking assumptions and pending confirmations.

Use When

Use this skill for requests such as:

• “根据会议纪要和Figma生成需求文档/PRD/md”
• “把设计稿和会议原文整理成需求文档”
• “根据Figma源文件补全需求详细逻辑”
• “输出【战绩玩法】需求文档”

Required Inputs

Collect or locate the following inputs:

1. Meeting-note original text, transcript, minutes, chat log, or raw requirement notes.
2. Figma source file or Figma URL/link. Accept Figma file links, prototype links, local exported Figma files, or attached design assets.
3. Optional: expected launch time, development workload, experiment/gray-release strategy, owner, business line, and existing PRD context.

If meeting notes or recordings are missing/incomplete but Figma is available, continue in Figma-first mode: infer product scope, user paths, UI states, and interaction logic from the design, then mark inferred or unverifiable business rules as 基于设计稿推断，待确认. If Figma is missing too, continue with available material and mark unverifiable sections as 暂无 or 待补充 according to the output rules.

Core Workflow

1. Ingest Meeting Notes

Extract the following facts from the meeting-note original:

• Business context, current pain points, target users, target scenario.
• Explicit feature scope, non-goals, constraints, dependencies, and risks.
• Stakeholders, business owners, front-end/back-end workload, timeline, rollout plan.
• Functional points, interaction rules, copy requirements, data display rules, exceptions, and open questions.
• Experiment strategy, gray-release percentage, target audience, metrics, and success criteria.

Preserve important wording when it affects product logic. Do not expand vague statements into specific rules unless the design supports them.

2. Inspect and Interpret Figma

When a Figma source file/link is present, load the figma skill before analysis. Use it to inspect file structure, pages, frames, components, variants, auto-layout hierarchy, text layers, annotations, prototypes, and exported assets as needed.

Use scripts/figma_extract.py as the built-in Figma recognition helper when an API token is available. The helper parses Figma URLs, extracts the file key and node id, calls the Figma REST API, and writes a compact JSON file containing file metadata, page/frame inventory, and target node data.

Run pattern:

python scripts/figma_extract.py "<figma-url>" "<output-json>"

Export screenshots for PRD illustrations with scripts/figma_export_images.py. Use the target node id from the Figma URL first; when multiple feature modules map to different frames, pass the mapped node ids explicitly.

python scripts/figma_export_images.py "<figma-url>" "<prd-assets-dir>"
python scripts/figma_export_images.py "<figma-url>" "<prd-assets-dir>" --ids "1086:4328,1086:4330" --format png --scale 2

Screenshot usage rule:

• Export screenshots for the frames/components that correspond to each core function point.
• Store screenshots in a PRD-local assets directory such as assets/figma/ or -assets/figma/.
• Insert screenshots in Markdown with relative paths whenever possible, for example !入口页.
• If Figma cannot be exported, keep the table row and write 待补充截图 in the illustration column.

Authentication rule:

• Read FIGMA_ACCESS_TOKEN from the environment or from a local .env file in the current working directory.
• Never request or print tokens in the final PRD.
• If no token is available or the file is private, continue from meeting notes and mark Figma-derived details as 待补充/待校验.

Identify and record:

• Design link, file/page/frame names, relevant node/frame identifiers, and exported screenshot paths if available.
• Main user flows represented by frames.
• Page modules, entry points, states, data fields, copy, buttons, labels, tabs, cards, popups, empty/loading/error states, and navigation targets.
• Component variants indicating business states, such as logged-in/out, owned/not owned, ranking states, visibility, permission, success/failure, disabled/enabled, or gray-release exposure.
• Prototype connections or annotations that imply interaction flows.

If Figma cannot be opened directly, use any provided screenshots/exports and clearly mark design-derived assumptions as based on exported material.

3. Associate Meeting Facts with Figma Evidence

Build a requirement-evidence map before writing:

• Match meeting requirements to Figma frames by feature module, UI text, entry path, data field, interaction, and state.
• Use meeting notes as the source of business intent and Figma as the source of screen-level behavior.
• Prefer explicit meeting-note statements for scope and rollout; prefer Figma for UI structure, page hierarchy, copy, states, and interaction details.
• When meeting notes and Figma conflict, document the conflict as 待确认 rather than choosing silently.
• When Figma contains screens not mentioned in meeting notes, include them only if they are part of the same flow, and mark their source as design稿补充.
• When meeting notes contain logic not represented in Figma, include it as requirement logic and mark UI待补充 if relevant.

4. Produce Markdown PRD

Use assets/prd-template.md as the output structure. Keep headings stable and output a clean .md document. When screenshots are exported, save them beside the PRD in a stable assets directory and reference them from the function-detail table with Markdown image syntax.

The PRD must include these sections in order:

1. # 需求标题
2. ## 1. 需求背景和目标
3. ## 2. 上线时间
4. ## 3. 设计稿
5. ## 4. 需求内容详细描述
6. ## 5. 灰度放量方案
7. ## 6. 埋点设计

5. Title Rule

Generate a concise requirement title:

• Format: 【战绩玩法】+ 自总结标题
• Total title text after the prefix should be concise and product-like.
• Keep the full title within 20 Chinese characters when possible.
• Example: 【战绩玩法】经典农场资料卡
• Avoid vague titles such as 【战绩玩法】需求整理.

6. Output Rules by Section

需求背景和目标

Write background, problem to solve, value, and expected effect. Use 暂无 if not mentioned and cannot be inferred.

上线时间

Include expected launch time and front-end/back-end workload only when mentioned. If all timing/workload information is absent, write 暂无.

设计稿

Place the original Figma/design link directly. If multiple links are provided, list all. If only local files or exports exist, list file names/paths.

需求内容详细描述

Follow the rules in references/prd-writing-rules.md. This section is the core output and must be written as a professional PM PRD, organized by user flow and functional module. For all major function descriptions, use a three-column Markdown table with 示意图、功能场景、需求详情; the illustration column should reference the exported Figma screenshot for the corresponding frame/node whenever available.

灰度放量方案

Translate experiment, gray-release, audience split, whitelist, staged rollout, or full-release strategy from the meeting notes. If no strategy is mentioned, write 暂无 or 默认全量发布（待确认） only when context clearly implies direct full release.

埋点设计

Reserve a placeholder only. Do not invent event names unless separately instructed. Output:

待补充：后续根据埋点规范补齐曝光、点击、转化及关键状态事件。

Quality Bar

Before finalizing, verify:

• Every important meeting-note requirement appears in the PRD or is explicitly marked 待确认/不在本次范围.
• When notes are missing or incomplete, every major Figma frame/state is converted into a PRD function row or a 待确认 item.
• Every major Figma screen/frame in scope is reflected in a function point or state description.
• Core function descriptions use the 示意图 / 功能场景 / 需求详情 table format and include exported screenshots or 待补充截图.
• Detailed logic is specific enough for development and QA to understand behavior.
• Unsupported assumptions are not presented as confirmed facts.
• Markdown headings match the required structure exactly.
• The design link is preserved without rewriting or shortening.