Skip to content
Productivity
Skill

/pm-tech

Use when: 需要与技术团队对接技术方案、评估技术可行性、制定技术架构、评估第三方服务 Do NOT use when: 技术方案已由技术团队确定、仅需功能描述无需技术评估

From plugin
super-pm
6648 skills1 hook
Install
$ npx -y skills add konglong87/superPM --skill pm-tech --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/pm-tech

Context preview

The summary Claude sees to decide when to auto-load this skill.

Use when: 需要与技术团队对接技术方案、评估技术可行性、制定技术架构、评估第三方服务 Do NOT use when: 技术方案已由技术团队确定、仅需功能描述无需技术评估

SKILL.md

pm-tech.SKILL.md
name: pm-tech
description: |
  Use when: 需要与技术团队对接技术方案、评估技术可行性、制定技术架构、评估第三方服务
  Do NOT use when: 技术方案已由技术团队确定、仅需功能描述无需技术评估
allowed-tools:
  - Agent
  - Read
  - Write
  - AskUserQuestion
  - Bash

Preamble (run first)

bash "$(dirname "${BASH_SOURCE[0]}")/../../check-update.sh" 2>/dev/null || true
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

---

跨 Agent 交互规则

当流程要求与用户交互时:

1. 如果当前环境支持 AskUserQuestion,使用 AskUserQuestion(最佳体验)。 2. 如果当前环境不支持 AskUserQuestion,必须用普通聊天消息提出同样问题。 3. 一次只问一个问题。 4. 提问后必须停止当前回合,等待用户回答(STOP and WAIT)。 5. 不得在用户回答前生成文档、写入 docs。 6. 已有 docs 文件不能替代本轮用户回答。

---

执行流程

步骤 1: 确定技术对接范围

使用 AskUserQuestion 询问:

> 您需要哪方面的技术对接支持? > > A) 整体技术方案(技术栈、架构、第三方服务) > B) 功能可行性评估(评估功能实现难度) > C) 接口设计(API接口规划) > D) 性能与扩展性(性能要求、扩展方案) > E) 其他(请手动输入) > > 💡 提示:产品规划→整体方案,功能设计→可行性评估,技术评审→接口设计

记录到变量 `TECH_SCOPE`

---

步骤 2: 读取前置数据

**必需文档**:PRD产品需求文档、原型设计方案(需其一) **可选文档**:MVP方案、需求调研报告

如果 PRD 不存在:

> ⚠️ 未找到 PRD 文档 > > 您可以选择: > A) 执行 /pm-docs 生成 PRD > B) 使用 MVP 方案作为输入 > C) 手动输入功能需求(快速模式)

---

步骤 3: 提取关键需求

从 PRD 提取:功能列表、非功能需求(性能/安全/兼容性)、数据需求 从原型设计提取:交互流程、页面复杂度

---

步骤 4: 技术方案设计

4.1 技术栈推荐

> 基于产品需求,推荐以下技术栈: > > **前端**:方案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) 已有技术栈约束

4.2 架构设计

> 📐 推荐架构方案: > - 前端层 → 接入层(Nginx) → 应用服务层 → 数据层 > - 核心模块:用户服务、业务服务、数据服务 > > A) 架构合理,继续 > B) 需要调整 > C) 我有其他想法

---

步骤 5: 功能可行性评估

5.1 逐个功能分析

对每个核心功能提交以下评估:

> 📋 **{功能名称}** > - **技术实现**:前端方案、后端方案、数据存储、第三方依赖 > - **难度**:⭐简单 / ⭐⭐中等 / ⭐⭐⭐复杂 > - **风险**:{风险点} > - **建议周期**:{预估时间} > > A) 继续评估下一个 > B) 需要调整这个功能 > C) 查看所有评估结果

5.2 高风险功能识别

> ⚠️ 高风险功能汇总:列出风险项及缓解方案(替代方案/分阶段/引入第三方) > > A) 接受推荐方案 > B) 需要进一步讨论 > C) 调整功能需求降低风险

---

步骤 6: 接口设计

6.1 核心API规划

> 🔌 核心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格式

6.2 接口详细设计(可选)

对关键接口提供详细设计:请求方法、路径、请求头、请求参数(JSON Schema)、响应参数、错误码

---

步骤 7: 第三方服务评估

7.1 服务推荐

> 🔧 第三方服务:支付(支付宝/微信)、短信(阿里云/腾讯云)、地图(高德/百度)、存储(OSS/COS)、推送(极光/个推)

7.2 成本预估

> 💰 成本参考:支付手续费0.6-1%,短信0.03-0.05元/条,存储{单价}/GB/月

---

Subagent 并行分析(v2.0 新增)

在步骤 4(技术方案设计)前,主 agent 可派发 subagent 并行执行独立分析任务:

使用 Agent 工具并行派发:

Agent 1: 技术栈调研
  - 调研各技术栈的社区活跃度、生态成熟度、人才市场
  - 输出:技术栈对比报告(JSON)

Agent 2: 成本预估
  - 估算开发成本、第三方服务费用、运维成本
  - 输出:成本预估明细(JSON)

Agent 3: 风险分析
  - 识别技术风险、替代方案、降级策略
  - 输出:风险评估矩阵(JSON)

主 agent 等待所有 subagent 完成,整合结果用于技术方案设计。

版本对比(v1 vs v2)

| 维度 | v1(串行) | v2(Subagent 并行) | |------|-----------|-------------------| | 技术栈调研 | 主 agent 手动分析 | Subagent 并行调研 | | 成本预估 | 手动计算 | Subagent 自动计算 | | 风险分析 | 逐个评估 | Subagent 并行评估 | | Token 占用 | 分析细节占用主上下文 | Subagent 独立上下文 | | 执行效率 | 线性顺序 | 并行 3x 加速 |

步骤 8: 输出技术对接方案

使用 Write 工具创建 `docs/02-方案设计/技术对接方案.md`。

参考 `references/output-template.md` 模板,填充用户输入数据。文档结构:

1. **技术概述** - 产品背景、技术目标 2. **技术栈选择** - 前端、后端、开发工具 3. **系统架构** - 整体架构、核心模块 4. **功能可行性评估** - 功能列表与难度、高风险分析 5. **API接口设计** - 规范、核心接口、详细设计 6. **数据库设计** - 核心表结构、索引 7. **第三方服务** - 服务清单、成本预估 8. **非功能性需求** - 性能、安全、可用性 9. **部署方案** - 部署架构、CI/CD 10. **项目风险与应对** 11. **开发排期建议** - 阶段划分、人力需求

---

兜底机制

场景: 无前置文档

如果PRD和原型都不存在,提供快速模式手动输入功能列表。

---

注意事项

1. 技术栈推荐应考虑团队现有技术积累 2. 接口设计遵循RESTful规范 3. 第三方服务成本需基于实际用量预估 4. 完整输出模板参见 `references/output-template.md`

---

输出质量对比

**✅ Good 示例**:

- 有数据引用:「根据 Q4 数据,留存率从 35% 降至 28%」
- 有验证来源:「数据来源:Google Analytics, 2025-12-01」
- 有明确建议:「建议将新手引导步骤从 5 步减少至 3 步」

**❌ Bad 示例**:

- 模糊结论:「数据表明留存率有所下降」
- 无来源:「根据经验,这个功能很重要」
- 没有行动建议:「留存是个问题」

---

常见误区 / Red Flags — STOP

出现以下情况立即停止并回溯:

| 误区 | 正确做法 | |------|---------| | 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 | | 未运行检查就声称已完成 | 先验证,再陈述 | | 因时间紧迫跳过关键步骤 | 没有例外,时间紧更要严格 | | "这次应该没问题"的想法 | 每次都要重新验证 |

---

产出质量检查 / Verification Checklist

  • [ ] 前置依赖已满足(输入文档/数据已收集)
  • [ ] 核心步骤已全部执行
  • [ ] 输出文档已生成到 `docs/` 目录
  • [ ] 每个判断都有数据/证据支撑
  • [ ] 已推荐 2-3 个后续 skill

> ⚠️ 任何一项未通过 → 补全后再标记完成。

---

Read more
Ships withsuper-pm

让每个产品经理都能轻轻松松的高效工作 ☕️ 📺 🚀

Get the whole plugin
Stats
65
Stars
8
Forks
Active
Maintenance
JavaScript
Language
MIT
License
11d ago
Last commit
5mo ago
Created

Repo: konglong87/superPM

Other skills on super-pm.

pm-brainstorm
Skill

pm-brainstorm

Use when: 需要创意方案、探索产品方向、发散思维、本质问题分析 用户说"我想做一个XX""帮我规划XX产品""帮我设计一下需求" 用户给出新产品方向,但尚未完成本轮 brainstorm 交互确认 新产品从0到1的第一步 Do NOT use when: 用户明确说"跳过 brainstorm /…

pm-clarify
Skill

pm-clarify

Use when: 有初步需求清单需要细化细节、需明确需求场景和边界条件、需求描述模糊需要结构化 Do NOT use when: 需求已足够详细可直达开发、仅需快速立项无需深入

pm-competitor
Skill

pm-competitor

Use when: 需要持续监控竞品动态、建立竞品情报预警、定期输出竞品监控月报、追踪竞品版本/定价/功能/舆情/融资异动 Do NOT use when: 仅需一次性竞品调研(用 pm-market / pm-search --type=competitor);产品尚无明确竞品

pm-demand
Skill

pm-demand

Use when: 已完成 /pm-brainstorm 后,需要系统化收集需求、验证产品想法真伪、分析用户痛点 用户明确要求"需求调研""需求验证""验证痛点""分析用户痛点" 用户明确选择跳过 brainstorm,直接进入需求调研 Do NOT auto-select when:…

pm-interview
Skill

pm-interview

Use when: 需要设计用户访谈/用户调研方案、编写访谈提纲、规划样本与招募、制定访谈执行与分析方法 Do NOT use when: 仅做案头需求调研(用 pm-demand);已有明确结论只需验证单一假设且无需访谈