القائمة
Use when: 需要与技术团队对接技术方案、评估技术可行性、制定技术架构、评估第三方服务 Do NOT use when: 技术方案已由技术团队确定、仅需功能描述无需技术评估
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Product Manager Skills Pack - Full lifecycle support from demand to delivery 让一个产品经理拥有一个产品团队的能力 Use when: Starting a new product, planning features, analyzing market, designing solutions, managing growth, strategic decision
Use when starting any product management task - automatically detects task type and invokes appropriate PM skill using intelligent routing
Use when: 需要检查super-pm skills健康状态、定期维护审计、验证元数据完整性 Do NOT use when: 正在使用某个功能skill、仅需执行产品管理任务
Use when: 有初步需求清单需要细化细节、需明确需求场景和边界条件、需求描述模糊需要结构化 Do NOT use when: 需求已足够详细可直达开发、仅需快速立项无需深入
Use when: 需要理解用户体验全链路、发现用户痛点与机会点、优化用户转化流程 Do NOT use when: 用户流程已非常清晰、仅需单一功能分析而非全局体验
Use when: 需要了解市场格局与竞争态势、收集行业数据、分析竞品优劣势、评估市场机会 Do NOT use when: 市场已有充分内部调研数据、仅需简单规模估算无需深度分析
استنادا إلى تصنيف SOC المهني
| name | pm-tech |
| description | Use when: 需要与技术团队对接技术方案、评估技术可行性、制定技术架构、评估第三方服务 Do NOT use when: 技术方案已由技术团队确定、仅需功能描述无需技术评估 |
| allowed-tools | ["Agent","Read","Write","AskUserQuestion","Bash"] |
bash "$(dirname "${BASH_SOURCE[0]}")"/check-update.sh 2>/dev/null || true
# 读取技能包版本号
SKILL_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")" 2>/dev/null && pwd)" || true
if [ -f "$SKILL_ROOT/VERSION" ]; then echo "📦 super-pm $(cat "$SKILL_ROOT/VERSION")"; fi
mkdir -p docs/02-方案设计
echo "📊 正在检查前置文档..."
if [ -f "docs/02-方案设计/PRD产品需求文档.md" ]; then
echo "✅ PRD文档 - 已找到"
else
echo "⏳ PRD文档 - 未找到"
fi
if [ -f "docs/02-方案设计/原型设计方案.md" ]; then
echo "✅ 原型设计方案 - 已找到"
else
echo "⏳ 原型设计方案 - 未找到"
fi
当流程要求与用户交互时：
使用 AskUserQuestion 询问：
您需要哪方面的技术对接支持？
A) 整体技术方案（技术栈、架构、第三方服务） B) 功能可行性评估（评估功能实现难度） C) 接口设计（API接口规划） D) 性能与扩展性（性能要求、扩展方案） E) 其他（请手动输入）
💡 提示：产品规划→整体方案，功能设计→可行性评估，技术评审→接口设计
记录到变量 TECH_SCOPE
必需文档：PRD产品需求文档、原型设计方案（需其一） 可选文档：MVP方案、需求调研报告
如果 PRD 不存在：
⚠️ 未找到 PRD 文档
您可以选择： A) 执行 /pm-docs 生成 PRD B) 使用 MVP 方案作为输入 C) 手动输入功能需求（快速模式）
从 PRD 提取：功能列表、非功能需求（性能/安全/兼容性）、数据需求 从原型设计提取：交互流程、页面复杂度
基于产品需求，推荐以下技术栈：
前端：方案A React+TS+Ant Design / 方案B Vue3+TS+Element Plus / 方案C 小程序原生 后端：方案A Java+Spring Boot+MySQL / 方案B Node.js+Express+MongoDB / 方案C Python+Django+PG / 方案D Go+Gin+MySQL
选择依据：团队熟练度、项目规模、性能要求、开发周期
A) 使用推荐方案 B) 需要调整 C) 已有技术栈约束
📐 推荐架构方案：
- 前端层 → 接入层(Nginx) → 应用服务层 → 数据层
- 核心模块：用户服务、业务服务、数据服务
A) 架构合理，继续 B) 需要调整 C) 我有其他想法
对每个核心功能提交以下评估：
📋 {功能名称}
- 技术实现：前端方案、后端方案、数据存储、第三方依赖
- 难度：⭐简单 / ⭐⭐中等 / ⭐⭐⭐复杂
- 风险：{风险点}
- 建议周期：{预估时间}
A) 继续评估下一个 B) 需要调整这个功能 C) 查看所有评估结果
⚠️ 高风险功能汇总：列出风险项及缓解方案（替代方案/分阶段/引入第三方）
A) 接受推荐方案 B) 需要进一步讨论 C) 调整功能需求降低风险
🔌 核心API接口：
用户模块：POST /api/auth/login, POST /api/auth/register, GET/PUT /api/user/profile 业务模块：GET /api/products, GET /api/products/{id}, POST /api/cart, POST /api/orders
是否需要详细设计某个接口？
A) 需要详细设计 B) 已经足够 C) 导出Swagger格式
对关键接口提供详细设计：请求方法、路径、请求头、请求参数（JSON Schema）、响应参数、错误码
🔧 第三方服务：支付(支付宝/微信)、短信(阿里云/腾讯云)、地图(高德/百度)、存储(OSS/COS)、推送(极光/个推)
💰 成本参考：支付手续费0.6-1%，短信0.03-0.05元/条，存储{单价}/GB/月
在步骤 4（技术方案设计）前，主 agent 可派发 subagent 并行执行独立分析任务：
使用 Agent 工具并行派发：
Agent 1: 技术栈调研
- 调研各技术栈的社区活跃度、生态成熟度、人才市场
- 输出：技术栈对比报告（JSON）
Agent 2: 成本预估
- 估算开发成本、第三方服务费用、运维成本
- 输出：成本预估明细（JSON）
Agent 3: 风险分析
- 识别技术风险、替代方案、降级策略
- 输出：风险评估矩阵（JSON）
主 agent 等待所有 subagent 完成，整合结果用于技术方案设计。
| 维度 | v1（串行） | v2（Subagent 并行） |
|---|---|---|
| 技术栈调研 | 主 agent 手动分析 | Subagent 并行调研 |
| 成本预估 | 手动计算 | Subagent 自动计算 |
| 风险分析 | 逐个评估 | Subagent 并行评估 |
| Token 占用 | 分析细节占用主上下文 | Subagent 独立上下文 |
| 执行效率 | 线性顺序 | 并行 3x 加速 |
使用 Write 工具创建 docs/02-方案设计/技术对接方案.md。
参考 references/output-template.md 模板，填充用户输入数据。文档结构：
如果PRD和原型都不存在，提供快速模式手动输入功能列表。
references/output-template.md✅ Good 示例：
- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
- 有验证来源：「数据来源：Google Analytics, 2025-12-01」
- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」
❌ Bad 示例：
- 模糊结论：「数据表明留存率有所下降」
- 无来源：「根据经验，这个功能很重要」
- 没有行动建议：「留存是个问题」
出现以下情况立即停止并回溯：
| 误区 | 正确做法 |
|---|---|
| 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 |
| 未运行检查就声称已完成 | 先验证，再陈述 |
| 因时间紧迫跳过关键步骤 | 没有例外，时间紧更要严格 |
| "这次应该没问题"的想法 | 每次都要重新验证 |
docs/ 目录⚠️ 任何一项未通过 → 补全后再标记完成。