pm-agile-workflow
Guides users through a stricter 7-step agile PM workflow. Invoke when users have a rough product idea and need interactive HTML prototype, PRD, mermaid flowcharts, and versioned delivery.
git clone https://github.com/antoninfatty836/pm-agile-workflow
T=$(mktemp -d) && git clone --depth=1 https://github.com/antoninfatty836/pm-agile-workflow "$T" && mkdir -p ~/.claude/skills && cp -r "$T/pm-agile-workflow" ~/.claude/skills/antoninfatty836-pm-agile-workflow-pm-agile-workflow && rm -rf "$T"
pm-agile-workflow/SKILL.md敏捷产品经理需求产出工作流 v1.0.0
触发方式
当用户提供一个初步的产品想法、功能需求、业务流程、草图、截图、口头描述,且希望最终得到可讨论、可演示、可继续迭代的 PRD + 交互 HTML 原型 + Mermaid 流程图 时,立即启用本技能。
🚨 绝对强制指令
- 必须严格按七个步骤推进,禁止一次性输出所有步骤结果。
- 每一个带有【等待用户确认】的步骤结束后,必须停止输出并等待用户回复。
- 在步骤一未完成前,不要创建文件、文件夹,不要直接产出 PRD,不要提前写原型。
- 原型是本技能的核心验证环节,不能弱化、更不能省略。
本技能的核心价值
- 帮用户把模糊需求逐步收敛成清晰业务逻辑。
- 先通过对话厘清问题,再用 HTML 原型验证交互与遗漏点。
- 最终产出可展示、可评审、可继续版本迭代的完整交付物。
适用场景
- 用户只有一个产品想法,还说不清流程和边界。
- 用户需要输出专业级 PRD,但又不希望只得到空框架。
- 用户需要交互式 HTML 原型来验证页面逻辑、异常流和信息结构。
- 用户希望 PRD 中直接嵌入原型切片,方便评审和对齐。
不适用场景
- 用户只要求修一段文案、改一个字段、补一个接口说明时,不必强行走完整七步。
- 用户已经明确只要单个文档、单个图、单个页面时,应先完成当前明确任务。
全局执行原则
- 所有输出都要围绕”帮助用户更快发现需求漏洞、交互问题与边界条件”展开。
- 初版 PRD 不能是空架子,必须带完整业务主线和关键逻辑。
- 原型必须是单文件 HTML,并包含可验证的关键状态。
- 每次用户调整原型,必须同步更新 PRD 中对应逻辑、规则和嵌入路径。
- 最终版 PRD 必须与原型、流程图、版本记录保持强一致。
- 自动打开预览:产出 HTML 文件后,必须自动在浏览器中打开,让用户直接看到效果。
对话风格要求
- 对用户说人话,专业但不生硬。
- 先复述理解,再展示缺口,再提出追问。
- 不要用机械问卷,不要要求用户先填模板。
- 追问要有启发性,要帮助用户想到之前没想到的问题。
步骤一:对话式需求采集与确认
目标
帮助用户把模糊需求讲清楚,并在开始写文档前完成充分澄清。
1.1 接收需求
- 接受任意形式输入,例如一句话、截图、草图、会议纪要、口语化描述。
- 先用自然语言复述你当前的理解,再进入维度评估。
1.2 必须展示的 7 个维度评估
收到用户初始需求后,必须直接把以下评估结果展示给用户:
- 背景/痛点:为什么要做,现状哪里不顺。
- 业务目标:这次做完希望改善什么指标或结果。
- 用户与场景:谁在什么情况下会使用。
- 核心用户旅程:用户从开始到完成目标会经历哪些关键步骤。
- 现有方案:现在怎么做,哪里效率低或体验差。
- 业务规则:是否存在审批、权限、时效、合规、数据约束。
- 参考/竞品:是否有参考产品、参考页面或喜欢的交互方式。
1.3 深度追问规则 【等待用户确认】
- 必须至少进行 3 轮追问。
- 每轮必须提出 3 到 5 个开放式、启发式问题。
- 每轮问题都要基于用户上一轮回答继续深入,不允许重复机械发问。
- 每轮提问后必须停止输出,等待用户回复。
- 只有当你确认已经完整理解需求,并且用户明确表示“没有补充了,可以开始写了”后,才能进入步骤二。
1.4 推荐输出结构
第一轮建议使用以下结构:
当前理解
- 用 3 到 6 句话总结用户现在想做什么。
需求清晰度评估
| 维度 | 当前状态 | 说明 |
|---|---|---|
| 背景/痛点 | 清晰/部分清晰/缺失 | ... |
| 业务目标 | 清晰/部分清晰/缺失 | ... |
| 用户与场景 | 清晰/部分清晰/缺失 | ... |
| 核心用户旅程 | 清晰/部分清晰/缺失 | ... |
| 现有方案 | 清晰/部分清晰/缺失 | ... |
| 业务规则 | 清晰/部分清晰/缺失 | ... |
| 参考/竞品 | 清晰/部分清晰/缺失 | ... |
本轮追问
- 问题 1
- 问题 2
- 问题 3
1.5 本步骤禁止事项
- 禁止创建目录或文件。
- 禁止提前开始写 PRD。
- 禁止在需求未确认前直接进入原型阶段。
步骤二:项目初始化与目录架构搭建
目标
在正式产出前建立清晰目录结构,让 PRD、原型、流程图和附件各归其位。
2.1 推荐目录命名
requirements/prototypes/flows/attachments/templates/
2.2 目录规则
- 根目录建议使用项目名。
- PRD 文件统一放在
requirements/ - 原型文件统一放在
prototypes/ - Mermaid 流程图源码或导出文件统一放在
flows/ - 原始资料、数据字典、补充材料统一放在
attachments/
2.3 对用户必须展示的内容
- 展示目录树
- 说明后续每一类产物的保存位置
- 告知后续版本迭代将沿用该结构
2.4 推荐目录树
<project-name>/ ├── requirements/ ├── prototypes/ ├── flows/ ├── attachments/ └── templates/
步骤三:输出详细的第一版初步 PRD
目标
基于步骤一确认过的信息,先产出一份足够详细、足够可讨论的 HTML 初版 PRD。
3.1 文件要求
- 必须使用 HTML 格式。
- 存放在
目录。requirements/ - 推荐命名:
prd_v1.0.html
3.2 初版 PRD 必须深度填充的内容
- 项目基本信息
- 需求背景与目标
- 用户使用场景与用户旅程
- 详细功能清单与基础业务逻辑
3.3 具体要求
- 需求背景与目标:必须使用四列表格,包含目标类型、描述、衡量指标、目标值。
- 用户旅程:必须覆盖阶段、用户触点、用户行为、痛点/情绪、产品机会点。
- 功能清单:不能只列模块名,必须写清主线流程、前置条件、规则和数据流向。
- 尚未确认的详细交互可以标注“待原型确认后补充”,但不能让主体内容空着。
3.4 用户确认话术 【等待用户确认】
该步骤结束时,必须向用户发出以下确认引导:
这是产品的详细第一版架构和业务逻辑,您看方向和基础逻辑准确吗?如果没问题,我们下一步先进入原型设计,通过具体画面进一步验证交互细节和可能遗漏的功能。
发出确认后必须停止输出,等待用户回复。
步骤四:产出高保真 HTML 原型(核心验证阶段)
目标
通过可交互的 HTML 原型,把抽象需求变成可以直接看到、点击、挑错的画面。
4.1 原型强制规范
- 必须产出 单文件 HTML 原型
- 文件中必须包含完整 CSS
- 强制使用 Tailwind CSS
- 页面风格应现代、清晰、适合评审
- 必须包含关键交互状态,例如默认态、弹窗态、空状态、成功态、失败态、加载态
- 可使用原生 JavaScript 或 URL Hash 做页面切换
4.2 Focus Mode 强制要求
为了支持 PRD 中的功能切片展示,原型必须支持专注模式:
- 必须解析 URL 参数中的
focus - 当
生效时,只允许对应功能区域可交互focus=<feature_id> - 其他区域必须弱化、锁定或遮罩
- 可以使用
、pointer-events: none
、遮罩层等方式实现opacity
4.3 推荐设计增强
在生成原型前,应主动提示用户:
为了让原型达到更专业的高级 UI 效果,如果当前环境已安装
或类似设计增强技能,我会优先调用它来生成更完整、更精致的界面。frontend-design
4.4 原型审查与迭代循环 【等待用户反馈】
- 生成原型后,必须自动在浏览器中打开原型文件,让用户直接预览
- 打开方式:使用 Bash 工具执行
(macOS)或open <文件路径>
(Windows)start <文件路径> - 必须主动引导用户从以下角度思考:
- 这里有没有缺少返回路径
- 如果断网或接口失败,应该怎么提示
- 如果为空数据,页面是否有引导
- 权限不足时该怎么处理
- 成功操作后用户下一步要去哪里
- 每次用户提出修改,都必须同步更新:
- 原型 HTML
- PRD 中对应功能的详细方案描述
- PRD 中嵌入原型的切片路径
- 只有当用户明确表示“完全满意”或“可以进入下一步”时,才可进入步骤五
步骤五:输出流程图(Mermaid)
目标
在原型跑通后,用 Mermaid 固化核心主线与异常分支。
5.1 格式要求
- 使用 Mermaid
- 推荐
或flowchart TDsequenceDiagram
5.2 内容要求
- 重点体现主操作链路
- 必须补充原型审查中暴露出的异常流程
- 应覆盖断网、失败、空状态、权限不足、校验失败等必要分支
- 书写时避免导致 Mermaid 渲染失败的特殊字符组合
5.3 推荐文件
- 存放位置:
flows/ - 推荐命名:
flowchart_v1.0.md
步骤六:产出最终版 PRD(内嵌原型与切片)
目标
整合前几步产物,输出一份真正可评审、可展示、可演示的最终 HTML PRD。
6.1 PRD 基本要求
- 必须使用语义话的 HTML 格式,确保独立打开即可使用,确保符合HTML5标准
- 必须有清晰目录导航
- 必须有良好的字体层级、留白、表格与模块布局
- 如环境可用设计增强能力,应优先提升排版与可读性
6.2 标准章节结构
- 项目信息与版本记录
- 一、需求背景
- 二、需求目标
- 三、用户与使用场景
- 四、需求功能清单
- 五、详细方案
- 六、业务流程图
- 七、异常与边界处理
- 八、数据追踪与埋点
- 九、未来演进规划
- 十、附件
6.3 详细方案的模块化要求
每一个核心功能点必须包含以下三部分:
- 交互逻辑流程图
- 详细规则描述
- 专注模式原型切片
6.4 iframe 切片规则
- 原型必须支持 Hash 路由,例如
prototype_v1.0.html#login - iframe 的
必须带src
参数,例如focus?sandbox=true&focus=login#login - 移动端原型可使用固定尺寸,如
375 x 812 - Web 端原型可使用响应式宽度
- iframe 必须设置
sandbox="allow-scripts allow-same-origin" - 建议移除边框,保证嵌入视觉整洁
6.5 推荐 HTML5 语义结构
<article class="feature-module"> <header class="feature-header"> <h3>功能:用户登录</h3> <p>用于说明该功能的目标、适用场景与核心价值。</p> </header> <section class="feature-content" style="display: flex; gap: 20px; align-items: flex-start;"> <section class="logic-rules" style="flex: 1;"> <section aria-labelledby="login-flow-title"> <h4 id="login-flow-title">交互流程图</h4> <div class="mermaid" role="img" aria-label="用户登录交互流程图"> flowchart TD ... </div> </section> <section aria-labelledby="login-rules-title"> <h4 id="login-rules-title">规则描述</h4> <dl> <dt>触发条件</dt> <dd>...</dd> <dt>交互反馈</dt> <dd>...</dd> <dt>异常处理</dt> <dd>...</dd> </dl> </section> </section> <aside class="sandbox-preview" aria-labelledby="login-prototype-title"> <h4 id="login-prototype-title">原型预览</h4> <figure> <iframe title="用户登录原型预览" src="../prototypes/prototype_v1.0.html?sandbox=true&focus=login#login" style="width: 375px; height: 812px; border: none;" sandbox="allow-scripts allow-same-origin" ></iframe> <figcaption>聚焦展示登录功能的交互原型切片。</figcaption> </figure> </aside> </section> </article>
6.6 交付检查
- 产出最终版 PRD 后,必须自动在浏览器中打开,让用户直接查看完整交付物
- 打开方式:使用 Bash 工具执行
(macOS)或open <文件路径>
(Windows)start <文件路径>
6.7 交付清单
- 是否包含清晰用户旅程图
- 是否每个核心功能都有 Mermaid 流程图
- 是否每个原型切片都开启 Focus Mode
- 是否补充断网、空数据、无权限等异常说明
- 是否保证 PRD 与原型路径完全一致
步骤七:版本迭代与管理
目标
让后续每次迭代都保留历史快照,并保持 PRD 与原型版本同步。
7.1 文件物理隔离
- 绝对不要覆盖历史版本
- 从
迭代到v1.0
时,必须复制:v1.1
→requirements/prd_v1.0.htmlrequirements/prd_v1.1.html
→prototypes/prototype_v1.0.htmlprototypes/prototype_v1.1.html
- 所有后续修改都在新版本文件中进行
7.2 PRD 内版本切换器
- 在 PRD 页面右上角增加版本切换下拉菜单
- 支持在
、v1.0
等版本间跳转v1.1 - 若当前页面是历史版本,建议显示明显提示横幅
7.3 变更日志与双向联动
- 在新版 PRD 的版本记录中写清新增、修改、下线内容
- 所有嵌入原型的 iframe 路径必须同步切换到对应版本
- PRD 与原型版本号必须严格一致
自动预览规则
在以下节点完成后,必须自动在浏览器中打开产出的 HTML 文件:
| 步骤 | 产出文件 | 自动打开 |
|---|---|---|
| Step 3 | | ✅ |
| Step 4 | | ✅ |
| Step 6 | | ✅ |
打开命令:
# macOS open requirements/prd_v1.0.html # Windows start requirements/prd_v1.0.html # Linux xdg-open requirements/prd_v1.0.html
注意: 必须使用 Bash 工具执行打开命令,不要让用户手动操作。
执行质量底线
- 不要把七步法压缩成一步完成
- 不要在用户未确认时自动跳步
- 不要只给静态文档,不做交互原型
- 不要只改原型,不改 PRD
- 不要给空洞框架式 PRD
- 不要覆盖历史版本文件
快速判断口诀
- 先问清,再建目录
- 先出初版 PRD,再做 HTML 原型
- 原型每改一处,PRD 同步一处
- 原型跑通后,再补 Mermaid 流程图
- 最终交付必须可读、可演示、可迭代
快速开始示例
用户输入:
"我想做一个积分兑换功能,用户可以用积分换商品"
执行过程:
Step 1 → 追问澄清:积分来源?兑换限制?库存处理?... Step 2 → 创建目录:requirements/ prototypes/ flows/ Step 3 → 输出 prd_v1.0.html(含功能清单、业务规则) Step 4 → 输出 prototype_v1.0.html(商品列表、兑换弹窗、成功/失败态) Step 5 → 输出 flowchart_v1.0.md(主流程 + 异常分支) Step 6 → 输出 prd_v1.0_final.html(内嵌原型切片) Step 7 → 版本记录、变更日志
最终产出:
points-exchange/ ├── requirements/ │ ├── prd_v1.0.html │ └── prd_v1.0_final.html ├── prototypes/ │ └── prototype_v1.0.html ├── flows/ │ └── flowchart_v1.0.md └── attachments/
前置依赖
| 依赖项 | 说明 | 是否必需 |
|---|---|---|
| Tailwind CSS | 原型样式,通过 CDN 自动引入 | 否(自动处理) |
| Mermaid.js | PRD 中流程图渲染,通过 CDN 自动引入 | 否(自动处理) |
| 现代浏览器 | Chrome / Firefox / Safari / Edge | 是 |
CDN 引入示例(原型中自动包含):
<!-- Tailwind CSS --> <script src="https://cdn.tailwindcss.com"></script> <!-- Mermaid.js(PRD 中使用) --> <script src="https://cdn.jsdelivr.net/npm/mermaid/dist/mermaid.min.js"></script>
推荐配合使用的 Skill
| Skill 名称 | 用途 | 场景 |
|---|---|---|
| frontend-design | UI 设计增强 | 需要更精致的界面效果时 |