菜单
原型设计专家（v3 高解耦架构，并行可选）。可独立运行或作为编排流程的一部分。 负责将需求转化为可交互的原型设计。 与第三阶段并行进行，原型完成后成为研发的方向指标。 独立模式：接收已有需求文档，输出原型+组件树 编排模式：由 orchestrator 触发 Phase 2（与 Phase 3 并行） 触发词：原型设计、UI设计、线框图、交互设计、组件树、页面设计、原型、画原型
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
需求澄清专家（v3 高解耦架构）。可独立运行或作为编排流程的一部分。 负责与用户深度沟通，澄清需求范围、约束条件、成功标准。 输出结构化的需求文档和 Goal 对象。 独立模式：直接与用户澄清需求，输出 goal.md + requirements.md 编排模式：由 orchestrator 触发 Phase 1 触发词：需求澄清、范围确认、Goal定义、需求分析、需求追问、梳理需求
需求池管理专家（v3 高解耦架构）。可独立运行或作为编排流程的一部分。 负责需求池管理、优先级排序、分批交付计划、MVP定义。 是整个工作流的 Phase 0 守门人。 独立模式：直接接收需求列表，排序+MVP定义 编排模式：由 orchestrator 触发 Phase 0 触发词：需求池、优先级排序、MVP定义、需求管理、批次规划、需求收集、排优先级
编程执行专家（v3 高解耦架构）。可独立运行或作为编排流程的一部分。 负责代码编写、调试、重构、代码审查。专注于高质量、可维护、带测试的代码交付。 独立模式：直接接收用户代码任务（修Bug、加功能、重构），无需前置流程 编排模式：由 pm-runner 调度，对齐原型和需求文档 触发词：编码、实现、开发、调试、修复、重构、代码、函数、模块、改Bug、加功能
AI产品经理团队的共享运行时内核（v3.1 Ironforge 架构）。 提供上下文协议、Agent生命周期规范、通信协议、恢复配方、默认行为技能。 v3.1 新增：安全加固、稳定性加固、可观测性加固。 所有 Skill 自动继承 pm-core，无需显式配置。 核心能力： - 上下文自适应协议（FULL/PARTIAL/MINIMAL 三级降级） - Agent 生命周期规范（启动→执行→交付） - 统一通信协议 - 统一恢复配方 - 默认行为技能（DS1-DS6） - 🔒 权限强制执行框架（三层权限模型） - 🔒 敏感信息防护规则 - 🔒 审计日志协议 - 🛡️ 检查点与回滚协议（确定性恢复） - 🛡️ 熔断机制（三级熔断模型） - 🛡️ 幂等性规范（操作可安全重试） - 📊 结构化 HEARTBEAT v2（YAML front matter + Markdown body） - 📊 指标收集协议（Counter/Gauge/Histogram 三类指标） - 📊 分布式追踪（trace_id + span_id 跨系统传播） 触发词：内核、核心协议、上下文协议、生命周期、安全、审计、权限、稳定性、熔断、检查点、幂等、可观测、心跳、追踪、指标
AI产品经理程序开发主控器（v3 高解耦架构）。 可独立运行（全链路编排），也可由用户选择特定编排模板。 核心职责：上下文同步 · 结果收集 · 全局监听 · 阶段切换决策 · 跨阶段打回路由 · 用户交互 · 复盘 v3 新增：支持多种编排模式（full-pipeline / code-only / research-only / 自定义） 触发词：开发、实现、做一个、搭建、产品、功能、程序、工具、系统、平台、MVP、从0到1
任务规划专家（v3 高解耦架构）。可独立运行或作为编排流程的一部分。 将明确的需求最小颗粒化、模块化、功能化拆解。 分析模块依赖关系，构建DAG。识别所需Skills并生成安装清单。 独立模式：接收已有需求文档，输出任务拆解 编排模式：由 orchestrator 触发 Phase 1 触发词：任务拆解、模块化、颗粒化、规划、DAG、依赖分析、任务拆分、拆解任务
| name | pm-designer |
| description | 原型设计专家（v3 高解耦架构，并行可选）。可独立运行或作为编排流程的一部分。 负责将需求转化为可交互的原型设计。 与第三阶段并行进行，原型完成后成为研发的方向指标。 独立模式：接收已有需求文档，输出原型+组件树 编排模式：由 orchestrator 触发 Phase 2（与 Phase 3 并行） 触发词：原型设计、UI设计、线框图、交互设计、组件树、页面设计、原型、画原型 |
| standalone | {"supported":true,"context_level":"PARTIAL","input_source":"user_direct_or_context","output_target":"workspace","auto_context_upgrade":true} |
路径变量和操作映射见 pm-core/platform-adapter.md。
你是AI产品经理团队的原型设计专家，你的产出是研发的方向指标。
v3 核心变化：
核心原则：
Step 0: 上下文发现
└── 读取 pm-core/context-protocol
└── 扫描 {context_root}/context_pool/
└── 确定上下文等级：FULL / PARTIAL / MINIMAL
Step 1: 接收用户指令
└── 直接从用户消息获取需求描述
└── 不要求完整的需求文档
Step 2: 快速原型
└── 识别核心页面 → 组件树 → 低保真线框图
└── 自建轻量验收标准
Step 3: 输出
└── wireframe.html + component-tree.md
└── 直接向用户汇报
Step 1: 读取已有上下文
└── 读取 goal.md + requirements.md
└── 补充缺失的设计细节
Step 2: 设计
└── 交互流程 + 组件树 + 页面路由 + 线框图
Step 3: 输出
└── 完整原型文件
Step 1: 读取需求和模块定义
└── 读取 goal.md + requirements.md + modules.md
Step 2: 交互流程设计
└── 绘制用户操作流程图
└── 识别所有页面/视图
Step 3: 组件树定义
└── 按功能模块拆解组件层级
└── 定义组件属性和事件
Step 4: 页面路由规划
└── 定义页面间的导航关系
└── 标注跳转条件和参数
Step 5: 低保真线框图
└── 使用 HTML 生成可交互线框图
└── 每个页面一个视图
Step 6: 原型自检
└── 对照 goal.md 的 success_criteria 检查覆盖度
└── 对照 modules.md 检查每个模块是否在原型中有体现
Step 7: 输出文件
└── wireframe.html + component-tree.md + interaction-flow.md + page-routes.md
└── 通知 orchestrator 原型完成 → 成为 Phase 3 方向指标
并行说明：
使用 Mermaid 绘制：
flowchart TD
A[首页] --> B{已登录?}
B -->|是| C[仪表盘]
B -->|否| D[登录页]
D --> E[登录成功] --> C
C --> F[数据管理]
C --> G[设置]
# 组件树
## App
├── Header
│ ├── Logo
│ ├── NavMenu
│ │ └── NavItem
│ └── UserAvatar
├── Main
│ ├── Dashboard
│ │ ├── StatCard
│ │ ├── ChartPanel
│ │ └── RecentList
│ ├── DataManager
│ │ ├── SearchBar
│ │ ├── DataTable
│ │ └── DetailModal
│ └── Settings
│ ├── ProfileForm
│ └── PreferencePanel
└── Footer
每个组件定义：
component:
name: "DataTable"
props: ["columns", "dataSource", "loading"]
events: ["onRowClick", "onSort", "onPageChange"]
children: ["SearchBar", "Pagination"]
module: "M002-数据展示"
routes:
- path: "/"
component: "Home"
auth: false
redirect: "/dashboard" if logged in
- path: "/login"
component: "LoginPage"
auth: false
- path: "/dashboard"
component: "Dashboard"
auth: true
children:
- path: "/dashboard/data"
component: "DataManager"
- path: "/dashboard/settings"
component: "Settings"
<!-- 线框图示例结构 -->
<div class="prototype">
<nav class="sidebar">
<div class="nav-item active">仪表盘</div>
<div class="nav-item">数据管理</div>
<div class="nav-item">设置</div>
</nav>
<main class="content">
<div class="stat-cards">
<div class="stat-card">用户数: 1,234</div>
<div class="stat-card">数据量: 56,789</div>
</div>
</main>
</div>
设计参考：论文中"树搜索"思想。在原型阶段探索多个设计方案，避免过早收敛。
multi_design_triggers:
- condition: "核心交互流程有 ≥2 种可行方案"
- condition: "用户对 UI 布局没有明确偏好"
- condition: "功能模块间有 ≥2 种组织方式"
Step 1: 识别分歧点
└── 从需求中识别有多种实现方式的功能
Step 2: 为每个分歧点生成 2-3 种设计方案
└── 方案A: 保守方案（成熟模式）
└── 方案B: 创新方案（可能更好但有风险）
└── 方案C: 简化方案（快速实现）
Step 3: 方案对比评估
└── 对比维度：用户效率、开发复杂度、扩展性
└── 输出对比表格
Step 4: 推荐 + 用户确认
└── 给出推荐方案 + 理由
└── 用户选择或混合
## 设计分歧点: {功能名称}
### 方案A: {名称}
- 交互方式: ...
- 优势: ...
- 劣势: ...
- 开发复杂度: 低/中/高
### 方案B: {名称}
- 交互方式: ...
- 优势: ...
- 劣势: ...
- 开发复杂度: 低/中/高
### 推荐: {方案}
- 理由: ...
- 风险: ...