Preamble (run first)
# 检查方案设计目录
# 检查前置文档
echo "📊 正在检查前置文档..."
if [ -f "docs/02-方案设计/PRD产品需求文档.md" ]; then
echo "✅ PRD文档 - 已找到"
else
echo "⏳ PRD文档 - 未找到"
fi
if [ -f "docs/01-需求调研/MVP方案.md" ]; then echo "✅ MVP方案 - 已找到" else echo "⏳ MVP方案 - 未找到" fi
---
## 写入时边界
只讨论时不写文件，启动检查不创建目录。用户要求保存产物时，先确认当前产品、精确输出路径及已有文件的覆盖/追加选择；确认后**仅在实际 Write 前**创建该输出文件的父目录。完整安装可参见 `skills/_shared/artifact-policy.md`，单独安装本 skill 也按本段执行。
---
## 跨 Agent 交互规则
当流程要求与用户交互时：
1. 如果当前环境支持 AskUserQuestion，使用 AskUserQuestion（最佳体验）。
2. 如果当前环境不支持 AskUserQuestion，必须用普通聊天消息提出同样问题。
3. 一次只问一个问题。
4. 提问后必须停止当前回合，等待用户回答（STOP and WAIT）。
5. 不得在用户回答前生成文档、写入 docs。
6. 已有 docs 文件不能替代本轮用户回答。
---
## 执行流程
### 步骤 1: 确定原型设计范围
使用 AskUserQuestion 询问：
> 您需要设计哪个层面的原型？
>
> A) 整体产品原型（完整产品流程）
> B) 核心功能原型（MVP核心流程）
> C) 单个功能模块原型（特定功能）
> D) 交互优化原型（已有原型的优化）
> E) 其他（请手动输入）
>
> 💡 提示：
> - 新产品从0到1 → 推荐整体产品原型
> - 快速验证 → 推荐核心功能原型
> - 迭代优化 → 推荐单个功能模块原型
记录到变量 `PROTO_SCOPE`
---
### 步骤 2: 读取前置数据
根据原型范围读取相应文档：
**必需文档**：
- PRD产品需求文档（如果存在）
- MVP方案（如果存在）
- 用户旅程地图（如果存在）
**读取失败处理**：
如果 PRD 文档不存在：
```markdown
⚠️ 未找到 PRD 文档
原型设计通常需要 PRD 作为输入，确保设计符合需求。
您可以选择：
A) 执行 /pm-docs 生成 PRD
B) 使用 MVP 方案作为输入（如果没有 PRD）
C) 手动输入功能需求（快速模式）
是否继续？
Step 3: Extract key information
Extract based on the preceding documents:
Extract from the PRD：
- Feature list
- Core business processes
- Interaction flows
- User scenarios
- Interface requirements
Extract from the MVP plan：
- Core feature set
- User journey
- Feature priorities
Extract from the user journey map：
- User operation paths
- Key touchpoints
- Emotion curve
Step 4: Design the prototype framework
4.1 Information architecture design
Use AskUserQuestion to ask:
Based on the functional requirements, I have organized the following information architecture:
{display the information architecture tree diagram}
Is this architecture reasonable?
A) The architecture is reasonable, continue designing the page flow B) The architecture needs adjustment C) I have other ideas (please enter manually)
If B is selected, guide the user to adjust the architecture.
4.2 Core page identification
AI analyzes and lists the core pages:
📱 Based on the information architecture and user journey, the following core pages have been identified:
{page list, such as: home page, product list, product details, shopping cart, order page, etc.}
Does it need adjustment?
A) The pages are complete, start designing the flow B) Pages need to be added C) Pages need to be removed D) Other adjustments
Step 5: Design the page flow
5.1 Sort out the core business processes
Based on the user journey and functional requirements, design the page navigation flow:
核心业务流程：
用户启动 → 首页 → 浏览商品 → 商品详情 → 加入购物车 → 结算 → 支付 → 订单完成
关键分支流程：
- 未登录用户：触发登录/注册流程
- 库存不足：提示缺货，推荐相似商品
- 支付失败：重试或更换支付方式
5.2 Interaction flow design
Use AskUserQuestion to design key interactions one by one:
Now design the interaction flow for the "{page name}" page:
Core features:
- {feature 1}
- {feature 2}
User operation paths:
- Trigger methods for entering the page
- Main action buttons
- Feedback after operations
- Page navigation logic
Are special interactions needed?
A) Standard interactions (commonly used components and patterns) B) Innovative interactions (new components need to be designed) C) Reference the interaction style of {competitor name} D) Other (please enter manually)
Step 6: Output the prototype design plan
Use the Write tool to create docs/02-方案设计/原型设计方案.md：
# {产品名称} 原型设计方案
## 文档信息
- **产品名称**: {从PRD提取}
- **原型范围**: {整体产品/核心功能/单个模块}
- **创建时间**: {当前时间}
- **设计工具**: super-pm
---
## 一、设计概述
### 1.1 设计目标
{从PRD或MVP方案提取：产品目标}
### 1.2 目标用户
{从PRD提取：目标用户}
### 1.3 核心场景
{从用户旅程或PRD提取：核心使用场景}
---
## 二、信息架构
### 2.1 整体架构
{product name} ├── Home page │ ├── Recommended content │ ├── Category entry │ └── Search entry ├── Category page │ ├── First-level category │ └── Second-level category ├── List page │ ├── Filter function │ ├── Sort function │ └── Product display ├── Details page │ ├── Basic information │ ├── Action buttons │ └── Related recommendations ├── Shopping cart │ ├── Product list │ ├── Quantity adjustment │ └── Checkout entry └── Personal center ├── Order management ├── Favorites └── Settings
### 2.2 导航设计
**主导航**：
- 首页
- 分类
- 购物车
- 我的
**辅助导航**：
- 搜索
- 客服
- 返回
---
## 三、页面设计详情
### 3.1 首页
**页面目标**：
- 快速触达用户感兴趣的内容
- 引导用户浏览和转化
**核心功能**：
- 搜索栏
- Banner轮播
- 推荐内容流
- 分类快捷入口
- 底部导航
**布局结构**：
┌─────────────────────┐ │ Logo 🔍 Search │ ← Top bar ├─────────────────────┤ │ │ │ Banner carousel │ │ │ ├─────────────────────┤ │ Quick entry (2x4 icons) │ ├─────────────────────┤ │ │ │ Recommended content feed │ │ (card-based layout) │ │ │ └─────────────────────┘ │ Home Categories Cart Me │ ← Bottom navigation └─────────────────────┘
**交互说明**：
- 下拉刷新内容流
- 上滑加载更多
- Banner自动轮播，手动可滑动
- 点击快捷入口跳转分类页
**异常处理**：
- 网络失败：显示占位图和重试按钮
- 内容为空：显示引导文案和推荐分类
---
### 3.2 {下一页面}
{重复上述结构}
---
## 四、交互流程
### 4.1 核心业务流程
**流程名称**：商品购买流程
**流程图**：
Home → Product list → Product details → Add to cart → Cart page → Checkout → Payment → Order complete
**详细步骤**：
1. **首页**
- 用户行为：浏览推荐内容或搜索商品
- 触发操作：点击商品卡片
- 页面跳转：进入商品详情
2. **商品详情**
- 用户行为：查看商品信息、选择规格
- 触发操作：点击"加入购物车"或"立即购买"
- 系统反馈：Toast提示"已加入购物车"
- 页面跳转：
- 加入购物车 → 留在当前页
- 立即购买 → 进入结算页
3. **购物车页**
- 用户行为：调整商品数量、选择商品
- 触发操作：点击"去结算"
- 前置检查：检查库存、价格变化
- 页面跳转：进入结算页
4. **结算页**
- 用户行为：选择收货地址、支付方式
- 触发操作：点击"提交订单"
- 页面跳转：进入支付页
5. **支付页**
- 用户行为：完成支付
- 触发操作：支付成功
- 页面跳转：进入订单详情
---
### 4.2 异常流程
**场景 1：商品库存不足**
Product details page → Add to cart → System checks inventory → Toast prompt "Insufficient stock"
**处理方式**：
- 显示库存不足提示
- 推荐"到货通知"功能
- 展示相似商品推荐
**场景 2：未登录用户下单**
Cart page → Proceed to checkout → Detect not logged in → Show login prompt → Login successful → Continue checkout
**处理方式**：
- 弹出登录引导框
- 支持：账号密码登录、短信登录、第三方登录
- 登录成功后自动继续流程
---
## 五、设计规范建议
### 5.1 视觉风格
**色彩方案**：
- 主色：{基于产品定位推荐}
- 辅助色：{推荐配色}
- 强调色：{用于重要按钮}
**字体规范**：
- 标题：16-20px 粗体
- 正文：14px 常规
- 辅助文字：12px 浅色
**间距规范**：
- 页面边距：16px
- 卡片间距：12px
- 元素间距：8px
---
### 5.2 组件规范
**按钮规范**：
- 主按钮：填充色，高度44px，圆角8px
- 次要按钮：描边，高度44px
- 文字按钮：无背景，高度自适应
**表单规范**：
- 输入框高度：48px
- 标签位置：左对齐或顶部对齐
- 错误提示：红色文字，输入框下方
**卡片规范**：
- 圆角：8px
- 阴影：0 2px 8px rgba(0,0,0,0.1)
- 内边距：16px
---
## 六、原型工具建议
### 6.1 工具选择
根据团队技能和项目需求，推荐以下工具：
**A) Figma（推荐）**
- 优势：协作便捷、组件库丰富、支持原型交互
- 适用：团队协作项目、需要实时评审
**B) Axure RP**
- 优势：交互功能强大、支持复杂逻辑
- 适用：需要高保真交互原型
**C) 墨刀 / 蓝湖**
- 优势：中文友好、上手快、支持协作
- 适用：快速原型、小型团队
**D) Sketch + Principle**
- 优势：设计精美、动画效果好
- 适用：偏重视觉设计的团队
---
### 6.2 设计资源
**组件库推荐**：
- Ant Design Mobile（通用）
- Material Design（国际化）
- WeUI（微信风格）
**图标库推荐**：
- iconfont（阿里巴巴图标库）
- Font Awesome
- Material Icons
---
## 七、下一步建议
### 7.1 原型设计完成后
建议执行：
1. **评审原型** - 与团队、stakeholder评审原型
2. **/pm-tech** - 技术对接，讨论可行性
3. **/pm-feature** - 功能细节拆解
4. **/pm-data** - 定义数据埋点需求
### 7.2 原型迭代优化
- 用户测试：招募目标用户测试原型
- 数据验证：关键页面加入数据埋点
- 快速迭代：基于反馈快速调整
---
## 八、附录
### 8.1 参考文档
- PRD产品需求文档
- MVP方案
- 用户旅程地图
### 8.2 设计检查清单
- [ ] 核心流程是否完整
- [ ] 异常流程是否覆盖
- [ ] 交互是否一致
- [ ] 加载状态是否考虑
- [ ] 空状态是否设计
- [ ] 错误提示是否友好
- [ ] 操作反馈是否及时
---
**文档状态**: 原型设计方案完成
**生成时间**: {时间戳}
**生成工具**: super-pm
Subagent parallel analysis (new in v2.0)
Before step 4 (design prototype framework), the main agent can dispatch subagents to execute independent analysis tasks in parallel:
使用 Agent 工具并行派发：
Agent 1: 竞品设计模式分析
- 收集竞品的页面结构和交互模式
- 输出：竞品设计模式报告（JSON）
Agent 2: 行业设计规范查询
- 分析行业通用的设计规范和最佳实践
- 输出：设计规范摘要（JSON）
Agent 3: 用户旅程推导
- 基于 PRD 和 MVP 方案推导用户操作路径
- 输出：用户旅程关键触点（JSON）
主 agent 等待所有 subagent 完成，整合结果用于原型框架设计。
Version comparison (v1 vs v2)
| Dimension | v1 (serial) | v2 (Subagent parallel) |
|---|---|---|
| Competitive analysis | Manual analysis one by one | Subagent parallel analysis |
| Design specifications | Manual lookup | Subagent automatic search |
| User journey derivation | Handled by main agent | Handled independently by Subagent |
| Token usage | Design details occupy main context | Subagent independent context |
| Execution efficiency | Linear sequence | Parallel 3x acceleration |
Step 7: Output completion prompt
Use AskUserQuestion to provide next-step options:
✅ Prototype design plan generated!
📄 Document path:
docs/02-方案设计/原型设计方案.md🎯 Suggested next steps:
A) Execute /pm-tech - Technical alignment (recommended) B) Execute /pm-feature - Feature detail breakdown C) Execute /pm-data - Data metric design D) View prototype design plan
Fallback mechanism
Scenario 1: PRD document does not exist
⚠️ 未找到 PRD 文档
原型设计通常基于 PRD 的功能需求。您可以选择：
A) 执行 /pm-docs 生成 PRD
B) 使用 MVP 方案作为输入
C) 手动输入功能需求
是否继续？
Scenario 2: User is unsure about design direction
Guide the user to think:
🤔 Not sure how to design?
I can help you: A) Analyze competitors' design patterns B) Derive design based on user journeys C) Provide general industry design solutions D) Refer to design specifications (e.g., Ant Design)
Notes
- Focus on core flows: Prioritize designing high-frequency core flows and avoid over-designing
- User perspective: Start from user usage scenarios rather than piling up features
- Interaction consistency: Keep interaction patterns unified to reduce learning costs
- Consider abnormal states: Not only design normal flows, but also consider errors, empty states, etc.
- Feasibility: Design must consider technical implementation difficulty and cost
Output File
- Prototype Design Plan →
docs/02-方案设计/原型设计方案.md
Output Quality Comparison
✅ Good Example：
- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
- 有验证来源：「数据来源：Google Analytics, 2025-12-01」
- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」
❌ Bad Example：
- 模糊结论：「数据表明留存率有所下降」
- 无来源：「根据经验，这个功能很重要」
- 没有行动建议：「留存是个问题」
Common Pitfalls / Red Flags — STOP
Stop immediately and backtrack if any of the following occur:
| Pitfall | Correct Approach |
|---|---|
| Drawing conclusions using "should", "probably", "seems" | Must be based on actual data and verification |
| Claiming completion without running checks | Verify first, then state |
| Skipping key steps due to time pressure | No exceptions; the tighter the time, the stricter you must be |
| The thought "it should be fine this time" | Re-verify every time |
Output Quality Check / Verification Checklist
- Prerequisite dependencies satisfied (input documents/data collected)
- All core steps executed
- Output document generated to the
docs/directory - Every judgment supported by data/evidence
- 2-3 follow-up skills recommended
⚠️ If any item fails → complete it before marking as done.