Preamble (run first)
# 检查是否有产品组合战略作为输入
if [ -f "docs/05-产品战略/产品组合战略.md" ]; then
echo "✅ 检测到产品组合战略文档，将基于此进行资源分配"
else
echo "⚠️ 未检测到产品组合战略文档，建议先执行 /pm-portfolio"
fi
Boundaries when writing
When only discussing, do not write files; startup checks do not create directories. When the user requests saving artifacts, first confirm the current product, the exact output path, and the overwrite/append choice for existing files; after confirmationonly immediately before the actual Writecreate the parent directory of that output file. For complete installation, see skills/_shared/artifact-policy.md, and installing this skill alone also follows this paragraph.
Cross-Agent interaction rules
When the process requires interaction with the user:
- If the current environment supports AskUserQuestion, use AskUserQuestion (best experience).
- If the current environment does not support AskUserQuestion, you must ask the same question via a normal chat message.
- Ask only one question at a time.
- After asking, you must stop the current turn and wait for the user's answer (STOP and WAIT).
- Do not generate documents or write to docs before the user answers.
- Existing docs files cannot replace the user's answer in this round.
Execution process
Step 1: Read prerequisite data
Read first：
docs/05-产品战略/产品组合战略.md
If the file does not exist, prompt the user:
⚠️ Product portfolio strategy document not found
You can choose: A) First run /pm-portfolio for product portfolio analysis B) Manually enter the product list (quick mode)
Step 2: Take stock of available resources
How to ask: use AskUserQuestion to ask one by one
Question 1: R&D team size
Use AskUserQuestion to ask:
What is the total number of people in the R&D team?
A) Fewer than 10 people (small team) B) 10-30 people (small to medium team) C) 30-50 people (medium team) D) 50-100 people (large team) E) More than 100 people (very large team) F) Other (please enter manually)
Question 2: Proportion of resources that can be invested
What proportion of R&D resources can be invested in new products/projects this quarter?
A) <20% (mainly maintaining existing products) B) 20-40% (a small portion of resources can be invested in new projects) C) 40-60% (resources are relatively sufficient) D) 60-80% (focus on investing in new projects) E) >80% (fully invest in new products)
Question 3: Key role configuration
What is the configuration of key roles in the team?
Ask one by one:
- Number of product managers: [number]
- Number of frontend engineers: [number]
- Number of backend engineers: [number]
- Number of test engineers: [number]
- Number of operations engineers: [number]
- Number of designers: [number]
Question 4: Resource constraints
What are the main constraints currently faced in resource allocation? (multiple choice)
A) Insufficient manpower B) Budget constraints C) Tight schedule D) Insufficient technical capability E) Other (please enter manually)
Step 3: Product resource demand assessment
Based on the product list read in Step 1, assess resource demand one by one:
Ask for each product：
Assessment item 1: Resource demand
How much R&D manpower does {product name} need this quarter?
A) Extremely high (requires core team members' full investment) B) High (requires a large amount of manpower) C) Medium (requires a moderate amount of manpower) D) Low (a small amount of manpower is sufficient) E) Maintenance mode (only maintenance manpower is needed)
Assessment Item 2: ROI Expectation
What is the expected return on investment (ROI) for {产品名称}?
A) Extremely high ROI (invest 1 yuan, output >10 yuan) B) High ROI (invest 1 yuan, output 5-10 yuan) C) Medium ROI (invest 1 yuan, output 2-5 yuan) D) Low ROI (invest 1 yuan, output <2 yuan) E) No ROI yet (strategic investment period)
Assessment Item 3: Time Urgency
How urgent is the launch timeline for {产品名称}?
A) Extremely urgent (must launch this quarter) B) Urgent (must launch next quarter) C) Moderate (launch within half a year is fine) D) Not urgent (launch within a year is fine) E) No clear time requirement
Assessment Item 4: Risk Level
What is the development risk level of {产品名称}?
A) High risk (high technical difficulty, high uncertainty) B) Medium risk (certain technical challenges) C) Low risk (mature technology, controllable risk) D) Extremely low risk (routine development)
Step 4: Resource Allocation Decision
Decision Logic：
- Priority Scoring Model
Calculate a priority score for each product:
优先级得分 = ROI得分 × 0.4 + 时间紧迫性得分 × 0.3 + 战略重要性得分 × 0.3 - 风险扣分
- Resource Allocation Matrix
| Priority | Resource Share | Description |
|---|---|---|
| P0 (Highest) | 30-40% | Core projects that must be completed |
| P1 (High) | 20-30% | Important projects, ensure delivery |
| P2 (Medium) | 10-20% | Secondary projects, adjust based on resource availability |
| P3 (Low) | <10% | Exploratory projects, execute when resources are sufficient |
- Conflict Resolution Mechanism
When resource demand > available resources:
- Prioritize ensuring P0 projects
- Delay P2-P3 projects
- Consider outsourcing or recruiting
Step 5: Generate Resource Allocation Plan
Use the Write tool to generate the document:
---
product: [产品组合]
created_at: [当前时间]
author: [用户]
skill: pm-resource
status: draft
---
# 资源分配方案
## 一、资源盘点
### 可用资源
**团队规模**: [X]人
**可投入新项目比例**: [X]%
**可用人力**: [X]人月
**关键角色配置**：
- 产品经理: [X]人
- 前端工程师: [X]人
- 后端工程师: [X]人
- 测试工程师: [X]人
- 运维工程师: [X]人
- 设计师: [X]人
**资源约束**：[人力不足/预算限制/时间紧迫...]
---
## 二、产品资源需求
| 产品名称 | 资源需求 | ROI预期 | 时间紧迫性 | 风险等级 | 战略重要性 |
|---------|---------|---------|-----------|---------|-----------|
| [产品A] | 极高 | 极高 | 极紧迫 | 中 | 核心战略 |
| [产品B] | 中 | 高 | 适中 | 低 | 重要战略 |
| ... | ... | ... | ... | ... | ... |
---
## 三、优先级排序
### P0级项目（最高优先级）
**项目列表**: [产品A, 产品C]
**优先级得分**: [90分, 85分]
**分配资源**: 35%人力
**理由**：
- [产品A]: ROI极高 + 时间紧迫 + 核心战略
- [产品C]: 高ROI + 明星产品阶段
---
### P1级项目（高优先级）
**项目列表**: [产品B]
**优先级得分**: [75分]
**分配资源**: 25%人力
**理由**：
- [产品B]: 现金牛产品，稳定收益
---
### P2级项目（中优先级）
**项目列表**: [产品D]
**优先级得分**: [60分]
**分配资源**: 15%人力
**理由**：
- [产品D]: 问题产品，需要验证
---
### P3级项目（低优先级）
**项目列表**: [产品E]
**优先级得分**: [45分]
**分配资源**: 5%人力
**理由**：
- [产品E]: 瘦狗产品，最小化投入
---
## 四、详细资源分配
### 季度资源分配表
| 产品名称 | 分配人力 | 前端 | 后端 | 测试 | 产品 | 设计 | 上线时间 |
|---------|---------|------|------|------|------|------|---------|
| [产品A] | 15人月 | 3人 | 5人 | 2人 | 2人 | 1人 | 3月底 |
| [产品B] | 10人月 | 2人 | 3人 | 2人 | 1人 | 1人 | 4月底 |
| [产品C] | 8人月 | 2人 | 2人 | 1人 | 1人 | 1人 | 5月底 |
| [产品D] | 5人月 | 1人 | 1人 | 1人 | 1人 | 0.5人 | 待定 |
| [产品E] | 2人月 | 0.5人 | 0.5人 | 0.5人 | 0.3人 | 0.2人 | 仅维护 |
---
## 五、资源冲突与解决方案
### 冲突1: 后端工程师不足
**问题描述**：
- 需求：15人
- 可用：10人
- 缺口：5人
**解决方案**：
1. 短期：外包3人，临时支援2人
2. 长期：招聘2人，培养内部人才3人
---
### 冲突2: 产品上线时间冲突
**问题描述**：
- 产品A和产品C都需要3月底上线
- 资源无法同时满足
**解决方案**：
1. 产品A优先上线（核心战略）
2. 产品C延后至4月中旬
3. 增加产品C的开发资源
---
## 六、风险控制
### 风险1: 关键人员离职
**影响**: 核心项目进度延误
**应对**:
- 建立知识转移机制
- 培养2名备份人员
- 关键模块文档化
### 风险2: 技术难度超预期
**影响**: 项目延期或失败
**应对**:
- 提前进行技术预研
- 预留20%缓冲时间
- 建立技术专家支持机制
---
## 七、监控指标
### 资源利用率
- 目标：80-85%利用率
- 监控频率：每周
- 预警阈值：<70% 或 >90%
### 项目进度偏差
- 目标：<10%偏差
- 监控频率：每周
- 预警阈值：>20%偏差
### ROI达成率
- 目标：>80%预期ROI
- 监控频率：每月
- 预警阈值：<50%预期ROI
---
## 八、下一步建议
建议执行：
1. /pm-decision - 战略决策支持（如外包、招聘等决策）
2. /pm-roadmap - 制定产品路线图
3. /pm-agile - 敏捷管理执行
---
**项目状态**: 资源分配方案制定完成
**生成时间**: [当前时间]
**生成工具**: super-pm
V2 Parallel Architecture Upgrade
Subagent Parallel Analysis
After the resource inventory is completed, subagents can be dispatched to execute in parallel:
Agent 1: Team Capacity Research
- Responsible for: estimating team capacity and manpower required for each product line based on historical data
Agent 2: Industry ROI Benchmark Query
- Responsible for: searching for benchmark data on resource input-output ratios in the same industry
- Search tool priority: prefer AnySearch (Bash call anysearch_cli.py (locate first: check ~/.claude/skills/anysearch/scripts/ ~/.opencode/skills/anysearch/scripts/ ~/.openclaw/skills/anysearch/scripts/ ~/.cursor/skills/anysearch/scripts/ ~/.anysearch/scripts/ or which anysearch_cli.py, then python3 <path> search), fall back to Exa MCP (mcp__exa__web_search_exa) on failure, and only use WebSearch as a last resort. When using WebSearch, mark it as degraded mode
V1 vs V2 Comparison
| Dimension | v1 (Serial) | v2 (Subagent Parallel) |
|---|---|---|
| Capacity Assessment | Rough estimate by the main agent | Data-based assessment by subagent |
| Industry Benchmark | No comparison data | Subagent automatically obtains benchmarks |
| Token Usage | Analysis occupies the main context | Subagent handles independently |
| Execution efficiency | Linear sequence | 2x parallel speedup |
Notes
- Resource buffer: It is recommended to reserve 10-15% of resources as a buffer
- Dynamic adjustment: Adjust resource allocation monthly based on project progress
- Risk contingency plan: Develop response plans in advance for key personnel departures, technical difficulties, etc.
- ROI tracking: Regularly review the actual output of resource investment
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 are satisfied (input documents/data have been collected)
- All core steps have been executed
- Output document has been generated to
docs/directory - Every judgment is supported by data/evidence
- 2-3 follow-up skills have been recommended
⚠️ If any item fails → complete it before marking as done.