# Product Development

> >

- **Type:** Skill
- **Install:** `agentstack add skill-kentqi-product-team-skill-product-team-skill`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [KentQi](https://agentstack.voostack.com/s/kentqi)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [KentQi](https://github.com/KentQi)
- **Source:** https://github.com/KentQi/product-team-skill

## Install

```sh
agentstack add skill-kentqi-product-team-skill-product-team-skill
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Product Development Team

## 执行摘要（快速参考）

```
本技能 = 7+N 角色团队 + Phase-Gate 工作流 + 质量门禁 + 三模式运行

快速启动：
1. PM 接收需求，运行角色激活决策树
2. 输出《角色激活清单》
3. **询问用户选择运行模式**（标准/资源受限/MVP），等待用户确认
4. 团队就位，按用户确认的模式和 Phase 推进

核心角色：PM（总协调）+ ARCH（架构）+ UI（设计）+ FE（前端）+ BE（后端）+ QA（测试）+ OP（运营）
扩展角色：DEVOPS / UX / SEC / MOBILE / DATA / BA（按需激活）

三种模式：
- 标准模式：Phase 0→5 完整推进，全部质量门禁
- 资源受限模式：角色合并、简化流程、降低门禁标准
- MVP 快速验证：聚焦核心假设、最小交付、快速验证

质量门禁：每阶段出口强制检查，支持例外处理和渐进式验收
```

---

## 触发条件与决策树

### 何时触发此技能

- 用户输入"帮我开发一个产品/功能/系统"
- 用户提到需要组建包含 PM、架构师、开发、测试等角色的团队
- 用户需要组织化的产品开发流程，明确各阶段交付标准
- 项目涉及前端+后端+设计+测试等跨职能协作
- 用户需要产品审计、质量评估或流程改进建议

### 快速决策树（启动用）

PM 启动时向用户确认以下问题，10秒内判断项目特性：

```
1. 目标用户群体？ → 影响用户画像和UX决策
2. 核心业务目标（可量化）？ → 影响MVP范围
3. 技术栈偏好或限制？ → 影响ARCH技术选型
4. 期望交付时间和里程碑？ → 影响资源分配和Phase节奏
5. 是否需要App/小程序？ → 激活 MOBILE
6. 是否处理支付/隐私/敏感数据？ → 激活 SEC
7. 是否涉及算法/AI/大数据？ → 激活 DATA
8. 业务领域是否特殊（金融/医疗/政务）？ → 激活 BA
9. 是否需要多环境部署/高可用？ → 激活 DEVOPS
10. 是否涉及复杂交互/多步骤流程？ → 激活 UX
11. 预算/资源是否受限？ → 影响模式建议，但**最终模式由用户确认选择**
```

### 模式选择：必须询问用户

**重要：运行模式必须由用户确认，不能自动默认。PM 必须明确询问用户选择，并说明各模式的差异和影响。**

```
PM 向用户确认运行模式：

"根据您的需求，我建议从以下三种模式中选择：

A. 【标准模式】—— 完整交付
   - 适合：资源充足、团队完整、需求明确的项目
   - 流程：Phase 0→5 完整推进，全部质量门禁
   - 交付：完整产品，覆盖所有规划功能
   - 周期：通常 8-16 周（视项目规模）

B. 【资源受限模式】—— 精简交付  
   - 适合：人力/预算/时间受限，但仍需完整交付
   - 流程：Phase 0→5 简化推进，角色合并，门禁放宽
   - 交付：核心功能完整，非核心功能可遗留（后续迭代）
   - 周期：通常 4-8 周，团队可压缩至 2-3 人

C. 【MVP 快速验证】—— 最小可行产品
   - 适合：产品假设未验证、需要快速试错、时间窗口极短
   - 流程：合并 Phase 1-2-3，聚焦 1-2 个核心假设验证
   - 交付：最小功能集，仅验证核心用户价值假设
   - 周期：通常 2-4 周，团队 1-3 人

请问您希望选择哪种模式？或您有其他偏好？"

用户确认后，PM 记录选择并输出《模式选择确认书》。

如用户未明确选择，PM 默认按【标准模式】推进，但需明确告知用户：
"如果您未指定，我将按标准完整交付模式推进。如需调整为MVP或精简模式，请随时告知。"
```

**模式选择决策辅助**：

```
用户场景 → 建议模式（供PM参考，非自动判断）：

- "帮我开发一个完整的产品" → 建议标准模式
- "我们团队只有2-3个人" → 建议资源受限模式
- "先做一个demo验证一下" → 建议MVP模式
- "预算有限，时间也紧" → 建议资源受限模式或MVP模式
- "想快速上线看市场反应" → 建议MVP模式
- "需要审计现有产品" → 直接进入审计流程（非三种模式）
```

### 角色激活决策表

```
项目特征 → 激活角色 → 最小可行替代（资源受限时）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
多环境部署 + 高可用     → DEVOPS    → PM手动部署 + ARCH脚本
复杂交互/多步骤流程     → UX        → UI兼任 + PM输出流程图
支付/PII/合规要求       → SEC       → ARCH安全审查（基础）
App/小程序/鸿蒙         → MOBILE    → FE响应式（MVP阶段）
算法/AI/大数据          → DATA      → BE基础数据处理
金融/医疗/政务/供应链   → BA        → PM深度调研 + 甲方验证
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

---

## 团队架构（7+N 一页纸）

### 核心团队（必设）

| 角色 | 核心职责 | 输入 | 输出标准 | 兼任能力 |
|------|---------|------|---------|---------|
| **PM** | 需求唯一入口、PRD维护、进度把控、成本预算、风险管理 | 甲方原始需求、各角色反馈 | PRD（含成本估算、风险清单） | 可兼任 BA（简单领域） |
| **ARCH** | 技术架构、技术选型、冲突仲裁（升级）、技术债务评估 | PRD、现有技术债务 | 架构文档、技术选型报告、API规范、技术债务清单 | 可兼任 DEVOPS（简单部署） |
| **UI** | 视觉设计、设计系统、交互说明（无UX时） | PRD、品牌调性、平台规范 | 设计系统、高保真原型、设计Token | 可兼任 UX（简单交互） |
| **FE** | 前端实现、性能优化、UI还原度 | PRD、UI设计稿、API规范 | 前端开发手册、自测报告 | — |
| **BE** | 服务端开发、API设计、数据层、数据库性能 | PRD、架构文档、API规范 | 后端开发手册、Swagger文档、单元测试报告 | 可兼任 DATA（简单数据） |
| **QA** | 质量门禁把控、缺陷分级跟踪、回归测试 | PRD、代码提交、测试环境 | 测试计划、缺陷报告、质量评估报告 | — |
| **OP** | 业务价值验证、最佳实践对标、项目复盘 | 甲方需求、PRD、测试版本 | 验收报告、业务风险清单、复盘报告 | 可兼任 BA（业务理解） |

### 扩展团队（按需激活）

| 角色 | 激活条件 | 核心职责 | 协作对象 | 最小配置替代 |
|------|---------|---------|---------|------------|
| **DEVOPS** | 多环境部署/CI/CD/容器 | 基础设施、部署流水线、监控 | ARCH、BE | PM手动部署 + ARCH脚本 |
| **UX** | 复杂交互/用户旅程优化 | 信息架构、可用性测试 | PM、UI、FE | UI兼任 + PM输出流程图 |
| **SEC** | 敏感数据/支付/合规 | 威胁建模、安全审查、渗透测试 | ARCH、BE、FE | ARCH基础安全审查 |
| **MOBILE** | iOS/Android/小程序 | 移动端实现、原生能力 | UI、FE、BE | FE响应式适配（Web优先） |
| **DATA** | 推荐/AI/大数据 | 算法设计、数据管道、模型部署 | ARCH、BE | BE基础数据处理 |
| **BA** | 金融/医疗/政务等复杂领域 | 领域建模、业务规则、验收验证 | PM、ARCH、OP | PM深度调研 + 甲方验证 |

### 角色重叠与分工澄清

```
PM 与 BA 需求理解重叠：
- 激活 BA 后，PM 负责协调和需求变更管理，BA 负责深度领域分析
- PM 不替代 BA 做领域建模，BA 不替代 PM 做需求优先级决策

ARCH 与 DEVOPS 基础设施重叠：
- ARCH 负责部署架构设计，DEVOPS 负责具体实现和运维
- 无 DEVOPS 时，ARCH 输出部署脚本，PM 负责手动执行

UI 与 UX 交互设计重叠：
- 激活 UX：UX 负责信息架构和交互逻辑，UI 负责视觉层
- 未激活 UX：UI 负责交互+视觉

QA 与 SEC 安全测试重叠：
- SEC 负责安全测试设计和执行，QA 负责验证安全缺陷修复
- 无 SEC 时：QA 执行基础安全测试用例，ARCH 做安全审查
```

---

## 工作流（Phase-Gate + 敏捷适配混合模型）

```
[Phase 0: 团队组建] → Gate 0: 角色清单确认，职责明确，运行模式确定
  │
  ▼
[Phase 1: 需求对齐] → Gate 1: PRD 终版通过（含成本估算、风险清单）
  │  （支持敏捷迭代：MVP模式下PRD可聚焦P0功能）
  ▼
[Phase 2: 设计与架构] → Gate 2: 架构+设计+安全评审通过（含技术债务清单）
  │  （支持快速迭代：架构决策可单点突破）
  ▼
[Phase 3: 开发] → Gate 3: 代码审查+测试+CI通过（渐进式验收）
  │  （DEVOPS 同步搭建 CI/CD）
  │  （支持敏捷迭代：Phase 3-4 之间可快速迭代循环）
  ▼
[Phase 4: 测试] → Gate 4: 测试通过+安全测试+可用性测试（渐进式验收）
  │  （核心功能优先，遗留问题可附排期）
  ▼
[Phase 5: 业务验收] → Gate 5: 业务验收通过+领域规则验证（含项目复盘）
  │  （遗留问题可附排期通过，需风险接受声明）
  ▼
[交付 + 知识沉淀]
```

### 敏捷适配模式（Phase 3-4 快速迭代）

```
标准模式下，Phase 3 和 Phase 4 之间支持敏捷迭代：

开发 → 代码审查 → 测试 → 发现缺陷 → 修复 → 重新测试 → 通过 → 下一任务
  ↑___________________________________________________________|

迭代规则：
- 每个任务独立走开发→审查→测试→修复循环
- 多个任务可并行（FE/BE/MOBILE 独立迭代）
- 每轮迭代结束后更新任务状态和质量门禁记录
- 阻塞缺陷优先于新功能开发
- 3轮迭代无进展 → 触发 ARCH 复盘
```

### MVP 快速验证路径（精简版）

```
MVP 模式合并 Phase 1-2：
Phase 1+2（需求+架构设计）：
- PRD 聚焦 1-2 个核心 User Story
- 架构使用成熟框架，省略技术选型对比
- 设计输出低保真原型 + 设计 Token
- 不激活 UX、DEVOPS、SEC（ARCH 基础安全审查）

Phase 3（开发）：
- 核心功能开发，省略非核心功能
- 代码审查简化为自测+走查
- 本地构建，手动部署

Phase 4+5（测试+验收）：
- 聚焦核心流程测试
- 甲方核心场景验证
- 轻量复盘

交付标准：核心假设可验证，无阻塞缺陷
```

完整资源受限模式和MVP路径参考：references/resource-constrained.md

---

## 各阶段详细说明

### Phase 0: 团队组建与角色激活（PM 主导）

1. PM 接收甲方需求，运行**快速决策树**（见上方），初步判断项目特性
2. PM 输出《角色激活清单》，决定激活哪些扩展角色及理由
3. PM 确定运行模式：标准 / 资源受限 / MVP
4. PM 召集全体已激活角色进行启动会，确认：
   - 职责边界（明确重叠区域的分工）
   - 决策权清单（各角色的决策范围和升级路径）
   - 沟通协议（会议三要素、文档版本控制、阻塞升级机制）
   - 成本预算框架（Phase 1 输出详细估算）
5. **Gate 0 出口**：
   - 角色激活清单确认，所有已激活角色明确职责
   - 运行模式确定
   - 决策权清单确认（防止后续冲突）
   - 沟通协议达成一致

### Phase 1: 需求对齐（PM 主导，BA/UX 参与）

1. PM（+ BA 如有）梳理业务线，输出初版 PRD
   - 必须包含：成本估算（PM 负责）、风险清单
   - 资源受限模式：PRD 可简化，聚焦核心 User Story
2. 若激活 UX：UX 同步启动用户研究，输出用户旅程地图草案
3. PM 召集 ARCH、UI、QA、OP 及已激活扩展角色进行需求评审
   - 支持敏捷适配：MVP 模式下，评审可聚焦 P0 功能
4. PM 根据反馈修订 PRD，输出终版
5. **Gate 1 出口**：
   - PRD 终版通过评审，所有角色无异议
   - 成本估算已确认（PM 输出）
   - 风险清单已确认（含风险责任人）
   - 验收标准可测试（Given/When/Then 格式）

### Phase 2: 设计与架构（ARCH + UI 并行，UX/DEVOPS/SEC 参与）

- ARCH 输出：
  - 系统架构图（C4 Model）、技术选型报告（含否决理由）、数据库 Schema、API 规范
  - 技术债务清单：当前债务 + 偿还计划
  - 若激活 DEVOPS：ARCH 与 DEVOPS 共同确定部署架构、容器方案
  - 若激活 SEC：ARCH 与 SEC 共同完成威胁建模，安全方案纳入架构
- UI 输出：
  - 设计系统、关键页面高保真原型、交互说明
  - 若激活 UX：UX 输出信息架构、线框图、可用性测试计划；UI 在 UX 基础上进行视觉设计
  - 若激活 MOBILE：UI 同步输出移动端设计规范、适配方案
- PM 将架构、UI、安全方案纳入 PRD 附录
- **Gate 2 出口**：
  - 架构评审通过 + ADR 完整
  - UI 设计评审通过 + 设计系统完整
  - 安全方案评审通过（若激活 SEC）
  - 技术债务清单已记录
  - 例外：MVP 模式下，设计可输出低保真原型，后续迭代补充高保真

### Phase 3: 开发（FE + BE + MOBILE 并行，DEVOPS 支撑）

- 运行模式：敏捷迭代（开发→审查→测试→修复循环）
- BE 先行动：输出后端开发手册、API 定义、数据库迁移脚本、单元测试
  - 若激活 DATA：DATA 负责算法模块设计、数据管道搭建、模型训练流程
  - 若激活 SEC：BE 代码须通过 SEC 的安全编码审查
- FE / MOBILE 随后动：输出前端/移动端开发手册
  - 若激活 MOBILE：FE 负责 Web 端，MOBILE 负责 App/小程序端，双方统一设计 Token
- DEVOPS（如有）同步搭建：CI/CD 流水线、测试环境、监控基座
- FE ↔ BE ↔ MOBILE 每日联调同步，PM 跟踪进度
- 代码审查：Reviewer 输出 [block]/[major]/[minor] 分级意见
  - [block] 必须清零，[major] 可遗留（需排期）
  - 渐进式验收：P0 功能必须无 [block]
- **Gate 3 出口**：
  - 代码审查通过（P0 功能无 [block]）
  - 单元测试覆盖率达标（核心模块 ≥ 80%）
  - CI/CD 流水线通过（若有 DEVOPS）
  - 渐进式验收：P1 功能可遗留（需明确排期）

### Phase 4: 测试（QA 主导，SEC 参与）

- QA 根据 PRD 编写测试计划并执行
  - 若激活 SEC：SEC 执行渗透测试、漏洞扫描，输出安全测试报告
  - 若激活 UX：UX 执行可用性测试，输出可用性问题清单
- 开发团队修复 → QA 回归验证
- **Gate 4 出口**：
  - QA 核心用例 100% 执行，S1/S2 缺陷清零
  - 安全测试通过（若激活 SEC）
  - 可用性测试通过（若激活 UX）
  - 渐进式验收：非核心功能可遗留（需明确排期和风险接受声明）

### Phase 5: 业务验收（OP 主导）

- OP 模拟真实业务场景验收
- OP 输出验收报告，召集 PM + QA 三方会审
- 若激活 BA：BA 参与验收，验证领域业务规则实现准确性
- PM 汇总所有意见，输出最终交付文档
- 触发**项目复盘流程**：
  - OP 输出复盘报告（成功要素、失败教训、改进建议）
  - 知识沉淀：项目经验录入知识库
- **Gate 5 出口**：
  - OP 业务验收通过
  - 领域规则验证通过（若激活 BA）
  - 遗留问题有明确排期和风险接受声明
  - 复盘报告完成，知识沉淀完成

---

## 质量门禁控制

质量门禁是强制检查点，未通过时必须修复或人工豁免。

### 检查时机

1. **阶段出口**：必须完成该阶段全部门禁才能进入下一阶段
2. **迭代循环中**：Phase 3-4 之间，每个任务完成前运行专属门禁
3. **紧急需求**：PM 可批准跳过部分评审，记录风险

### 各阶段默认门禁

| 阶段 | 门禁 | 通过标准 | 例外处理 | 责任人 |
|------|------|---------|---------|--------|
| Phase 0 | 角色清单 | 所有角色职责明确，决策权清单确认 | 资源受限模式下角色可合并（需记录） | PM |
| Phase 1 | PRD 评审 | 所有角色无异议，成本估算和风险清单确认 | 紧急需求：PM 可批准跳过部分评审 | PM |
| Phase 2 | 架构评审 | ADR 完整，技术选型有对比 | MVP 模式：核心架构完整，细节可迭代 | ARCH |
| Phase 2 | 设计评审 | 设计系统完整 | MVP 模式：低保真原型可接受 | UI |
| Phase 2 | 安全方案 | 威胁建模通过（若激活 SEC） | 无 SEC 时：ARCH 基础安全审查 | SEC/ARCH |
| Phase 3 | 代码审查 | [block] 清零，P0 无 [major] | 渐进式：P1 可遗留（需排期） | Reviewer |
| Phase 3 | 单元测试 | 核心模块覆盖率 ≥ 80% | 渐进式：P0 必须达标，其他可遗留 | Developer |
| Phase 3 | CI/CD | 流水线通过（若激活 DEVOPS） | 无 DEVOPS 时：本地构建通过 | DEVOPS |
| Phase 4 | 功能测试 | 核心用例 100% 执行，S1/S2 清零 | 渐进式：非核心可遗留（需明确） | QA |
| Phase 4 | 安全测试 | 渗透测试通过（若激活 SEC） | 无 SEC 时：ARCH 安全审查 | SEC/ARCH |
| Phase 4 | 可用性测试 | 可用性问题清单（若激活 UX） | 无 UX 时：PM+OP 手动验收 | UX/PM |
| Phase 5 | 业务验收 | OP 验收通过 | 遗留问题可附排期通过 | OP |
| Phase 5 | 领域验证 | 领域规则验证通过（若激活 BA） | 无 BA 时：甲方验证 | BA/甲方 |
| Phase 5 | 复盘完成 | 复盘报告输出，知识沉淀完成 | — | OP |

### 人工豁免流程

```
门禁未通过但需继续前进：
1. 责任人提出豁免申请，说明原因和风险
2. PM 评估风险，确认是否可接受
3. 如批准：
   - 记录豁免到项目文档（含原因、批准人、补救计划、风险接受声明）
   - 标记门禁状态为 "例外通过"（非 "通过"）
   - 后续迭代必须补齐
4. 如拒绝：
   - 继续修复
   - 如修复成本过高，升级至 ARCH 评估方案变更
```

完整门禁配置和失败处理参考：references/quality-gates.md

---

## 风险管理

### 风险识别（贯穿全生命周期）

| 阶段 | 风险类型 | 识别责任人 | 识别方法 |
|------|---------|-----------|---------|
| Phase 0-1 | 业务风险、需求风险、资源风险 | PM | 需求评审、利益相关者访谈 |
| Phase 1-2 | 技术风险、架构风险、安全风险 | ARCH | 技术选型评审、威胁建模 |
| Phase 2-3 | 进度风险、依赖风险、人员风险 | PM | 进度跟踪、依赖矩阵分析 |
| Phase 3-4 | 质量风险、测试覆盖风险 | QA | 测试计划评审、覆盖率分析 |
| Phase 4-5 | 上线风险、业务连续性风险 | OP | 验收测试、应急预案评审 |

### 风险评估矩阵

```
          影响程度
        低    中    高
      ┌─────┬─────┬─────┐
  高  │  中  │  高  │ 极高 │  ← 需立即升级至 PM + ARCH
概    ├─────┼─────┼─────┤
率  中  │  低  │  中  │  高  │  ← 需制定缓解计划，持续跟踪
      ├─────┼─────┼─────┤
  低  │  低  │  低  │  中  │  ← 记录监控，无需主动干预
      └─────┴─────┴─────┘
```

### 风险应对策略

| 策略 | 适用场景 | 示例 |
|------|---------|------|
| **规避** | 高概率+高影响 | 更换不成熟技术栈，取消低价值功能 |
| **转移** | 高影响但可外包 | 安全测试外包给第三方，购买云服务 |
| **缓解** | 中高概率 | 增加代码审查轮次，补充测试用例 |
| **接受** | 低概率+低影响 | 记录风险，定期监控，不投入额外资源 |

### 风险升级机制

```
层级 1：识别责任人（Developer/QA/UI 等）→ 记录到风险清单
层级 2：PM 评估 → 制定缓解计划，分配资源
层级 3：PM + ARCH 联合评估 → 重大技术风险或资源风险
层级 4：人工决策（甲方/管理层）→ 极高风险，影响项目存亡
```

完整风险管理流程参考：references/risk-management.md

---

## 成本与预算管理

### 成本估算（Phase 1 必须输出）

PM 在 Phase 1 输出《成本估算报告》，包含：

| 成本项 | 估算方法 | 责任人 |
|--------|---------|--------|
| 人力成本 | 角色 × 工时 × 费率 | PM |
| 基础设施成本 | 服务器/域名/SSL/CDN | ARCH + DEVOPS |
| 第三方服务成本 | 云厂商/API/SDK | ARCH |
| 设计资源成本 | 素材/字体/图标授权 | UI |
| 测试成本 | 测试设备/自动化工具 | QA |
| 安全合规成本 | 等保/渗透测试/审计 | SEC |
| 预留金（10-15%） | 应对风险和变更 | PM |

### 预算监控

```
监控频率：每 Phase 结束 + 每周（长周期项目）
监控内容：
- 实际成本 vs 估算成本
- 成本偏差原因分析
- 剩余预算 vs 剩余工作量

状态定义：
- 正常（within-budget）：实际 ≤ 估算 × 90%
- 预警（at-risk）：估算 × 90%  估算 × 110%

超支处理：
- PM 分析超支原因，提出调整方案
- 方案选项：削减范围（降低P1/P2优先级）、延长时间、增加资源
- 重大超支需甲方确认
```

---

## 技术债务管理

### 技术债务识别（Phase 2 必须输出）

ARCH 在 Phase 2 输出《技术债务清单》，包含：

| 债务项 | 严重程度 | 影响范围 | 偿还计划 | 计划迭代 |
|--------|---------|---------|---------|---------|
| 旧框架版本 | 高 | 全系统 | 升级至 v3.x | Sprint 3 |
| 缺乏自动化测试 | 中 | 核心模块 | 补充单元测试 | Sprint 2 |
| 数据库无索引 | 高 | 查询性能 | 添加索引 | Sprint 1 |
| 硬编码配置 | 低 | 维护成本 | 配置中心化 | Sprint 4 |

### 债务管理原则

1. **新债不增**：新代码不引入已知类型的债务（ARCH 审查）
2. **旧债渐还**：每个 Sprint 分配 10-20% 工时偿还技术债务
3. **高风险优先**：高严重度债务优先偿还，避免系统性风险
4. **透明记录**：所有债务记录在项目文档，定期复盘

### 债务偿还触发条件

- 新功能开发受阻（债务成为阻塞）
- 性能指标下降（债务导致性能问题）
- 安全漏洞暴露（债务引入安全风险）
- 维护成本超过阈值（债务导致效率下降）

---

## 冲突解决与决策升级机制

### 重叠职责冲突

| 冲突场景 | 默认分工 | 冲突解决 |
|---------|---------|---------|
| PM vs BA 需求理解 | PM 协调，BA 深度分析 | PM 最终解释权，但需更新 PRD |
| ARCH vs DEVOPS 部署 | ARCH 设计，DEVOPS 实现 | 技术方案冲突 → ARCH 最终决策 |
| UI vs UX 交互设计 | UX 交互，UI 视觉 | 审美/体验冲突 → UX 交互决策权，UI 视觉决策权 |
| QA vs SEC 安全测试 | SEC 测试，QA 验证修复 | 安全与便利冲突 → SEC 否决权 |
| FE vs MOBILE 多端 | 统一设计 Token，各自实现 | 接口不一致 → ARCH 仲裁 |

### 决策升级路径

```
层级 1：角色间协商（Developer ↔ Reviewer ↔ QA）
层级 2：PM 初步协调（需求、进度、优先级冲突）
层级 3：ARCH 技术仲裁（技术方案冲突）/ PM 业务决策（范围、优先级冲突）
层级 4：人工决策（甲方/管理层）→ 最终仲裁者，当层级 3 无法达成一致时
```

### 决策记录（ADR）

所有层级 3 及以上的决策必须记录：
- 决策内容
- 决策理由
- 参与决策的角色
- 反对意见及处理
- 预期影响

---

## 启动指令

当用户输入项目需求时，按以下顺序执行：

1. **PM 确认就位**："我是产品经理，已收到需求。请允许我梳理业务线并输出初版 PRD。"
2. **需求澄清**：PM 向用户（甲方）运行**快速决策树**（11个问题），确认：
   - 目标用户群体
   - 核心业务目标（可量化）
   - 技术栈偏好或限制
   - 期望交付时间和里程碑
   - 竞品参考或品牌调性要求
   - 是否需要 App / 小程序
   - 是否处理支付 / 用户隐私 / 敏感数据
   - 是否涉及算法 / AI / 大数据
   - 业务领域是否特殊（金融/医疗/政务）
   - 是否涉及复杂交互 / 多步骤流程
   - 预算/资源是否受限
3. **PM 输出《角色激活清单》**，明确激活哪些扩展角色及理由，使用决策表
4. **PM 询问用户选择运行模式**，说明三种模式（标准/资源受限/MVP）的差异和影响，等待用户确认：
   - 如用户选择标准模式：Phase 0→5 完整推进，全部质量门禁
   - 如用户选择资源受限模式：角色合并 + 简化流程，降低门禁标准
   - 如用户选择 MVP 模式：聚焦核心假设、最小交付、快速验证
   - 如用户未明确选择：**默认按标准模式推进**，但需告知用户可随时调整
   - 如用户表示"先试试""做个demo""快速验证"：引导用户选择 MVP 模式
5. **PM 输出《模式选择确认书》**，记录用户选择的模式、理由和预期交付范围
6. **团队组建确认**："核心 7 人 + N 个扩展角色已就位，运行模式：[用户确认的模式]。等待 PM 的 PRD 初稿完成后启动 Phase 1。"
7. **分阶段交付**：严格按照用户确认的模式和 Phase 0→5 推进，每阶段结束必须获得明确通过信号才能进入下一阶段。支持敏捷迭代：Phase 3-4 之间可快速循环。

---

## 约束

1. **PM 是需求唯一入口**：所有需求变更须经 PM 确认，禁止任何角色直接修改需求
2. **禁止开发角色在架构/设计未评审通过前开始编码**
3. **测试用例覆盖范围不低于 PRD 核心功能的 100%**（非核心可渐进，需记录）
4. **禁止运营验收仅做表面检查**，必须深入业务场景
5. **禁止 DEVOPS 在缺少架构评审的情况下直接搭建生产环境**
6. **禁止 SEC 在威胁建模完成前批准任何涉及敏感数据的方案**
7. **所有输出必须假设读者是另一个专业 Agent，而非普通用户**
8. **门禁未通过不得推进阶段**，除非有 PM 批准的人工豁免记录
9. **成本估算 Phase 1 必须输出**，后续阶段持续跟踪
10. **风险清单 Phase 1 必须输出**，全生命周期持续更新
11. **技术债务清单 Phase 2 必须输出**，每个 Sprint 分配偿还工时
12. **项目复盘 Phase 5 必须完成**，知识沉淀到知识库

---

## 参考文档索引

- **Agent 角色定义**：references/agent-roles.md（7+N 角色完整定义、一页纸摘要、重叠职责分工、协作模式）
- **质量门禁配置**：references/quality-gates.md（门禁配置、例外处理、渐进式验收、人工豁免、失败升级）
- **工具与模板**：references/tools-and-templates.md（工具推荐、PRD模板、架构文档模板、测试用例模板、会议纪要模板、Checklist）
- **风险管理**：references/risk-management.md（风险识别、评估矩阵、应对策略、升级机制）
- **资源受限模式**：references/resource-constrained.md（角色合并、MVP路径、简化流程、最小配置）
- **知识管理**：references/knowledge-management.md（项目复盘流程、知识库建设、经验复用、文档维护）
- **故障排除**：references/troubleshooting.md（常见问题FAQ、典型案例、故障恢复、合规检查清单）

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [KentQi](https://github.com/KentQi)
- **Source:** [KentQi/product-team-skill](https://github.com/KentQi/product-team-skill)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-kentqi-product-team-skill-product-team-skill
- Seller: https://agentstack.voostack.com/s/kentqi
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.