Run any Skill in Manus with one click

Get Started

task-decomposition

Stars1

Forks0

UpdatedMarch 26, 2026 at 05:18

把一个较大的 PM、AI PM 或商业化任务拆成可快速验证的执行步骤。适用于任务过大、容易失控、需要先把执行顺序和检查点想清楚的场景。

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

lujuncheng1225-cloud

lujuncheng1225-cloud/AI_Commercialization--Product-Management-skills

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Project Management SpecialistsBusiness and Financial Operations Occupations·SOC 13-1082

SKILL.md

readonly

name	task-decomposition
description	把一个较大的 PM、AI PM 或商业化任务拆成可快速验证的执行步骤。适用于任务过大、容易失控、需要先把执行顺序和检查点想清楚的场景。
type	component
best_for	["把大任务拆成小步骤","降低 PRD、评审或分析任务的失控风险","给 agent 或团队生成可执行计划"]
scenarios	["把一份复杂 PRD 写作任务拆成 30 分钟内可推进的步骤","把一次商业化诊断拆成若干可验证的小任务"]

Purpose / 用途

在真正执行前，先把大任务拆成一串足够小、足够清楚、每步都能检查的动作，避免“直接开做然后一路漂移”。

Key Concepts / 核心概念

Atomic Step Rule / 原子步骤规则

每一步都应该：

只解决一个主要问题
有清楚输出
完成后能立即检查是否过关

如果一个步骤完成后仍然不知道“算不算做完”，说明还不够小。

Risk-First Ordering / 风险优先排序

优先做：

能暴露方向错误的步骤
能减少后续返工的步骤
能显著影响方案选择的步骤

不要把最关键的不确定性留到最后。

Review Hook / 审查挂钩

好拆解不只是顺序清单，还要写出：

哪一步之后应该停下来复核
哪些结果会导致回退
哪些步骤可以并行，哪些必须串行

Application / 用法

## Task Decomposition

### Goal
[这次任务最终要交付什么]

### Assumptions
- [关键假设]

### Work Steps
1. [步骤]
   - Output: [产出]
   - Check: [如何判断过关]

2. [步骤]
   - Output: [产出]
   - Check: [如何判断过关]

### Review Points
- [在哪些节点复核]

### Stop / Rework Conditions
- [什么情况下暂停或返工]

Examples / 示例

好：

“先确认问题定义，再拆成功指标和范围，最后才写详细需求；每一步结束后都能检查是否过关。”

差：

“先写一版再慢慢改。”

Strong Example / 强样例

## Task Decomposition

### Goal
产出一份面向新用户 onboarding 改版的 PRD 草案，并能支持设计和工程进入细化讨论。

### Assumptions
- 当前最大问题发生在首次价值出现前
- 本轮先解决激活，不同时处理邀请后的协作问题

### Work Steps
1. 重新确认问题定义
   - Output: 一段明确的问题陈述
   - Check: 能回答“谁卡住、卡在哪、为什么现在要解决”

2. 拆出 success metrics 和 guardrails
   - Output: 1 个主指标 + 2-3 个配套指标
   - Check: 指标能支持 go / no-go 判断，而不只是观察

3. 收敛本轮 scope
   - Output: must-have / out-of-scope 清单
   - Check: 每个 must-have 都能解释它如何影响主指标

4. 写核心流程和需求
   - Output: PRD 主体
   - Check: 方案、范围、风险之间没有明显冲突

5. 做交付前复核
   - Output: 返工点或可交付结论
   - Check: 至少经过一次 fit / reasoning / integration 审查

### Review Points
- Step 1 后复核是否把方案误写成问题
- Step 3 后复核是否 scope 失控
- Step 5 后决定是否可直接交付

### Stop / Rework Conditions
- 如果问题定义无法支撑主指标，停止写 PRD，回到 discovery
- 如果 must-have 超过本轮资源上限，回到 scope 收敛

Common Pitfalls / 常见误区

步骤太大，一步里混了多个决策
只写动作，不写产出和检查点
明明存在高风险假设，却把验证放到最后

References / 关联项

../workshop-facilitation/SKILL.md
../problem-statement/SKILL.md
../prd-development/SKILL.md
../experiment-brief/SKILL.md

More from this repository

same repository

pricing-packaging-brief

lujuncheng1225-cloud/AI_Commercialization--Product-Management-skills

用结构化输入定义或调整定价与套餐结构，明确目标客户、价值指标、免费层边界、套餐层级、升级触发点与风险取舍。适用于定价新建、改版、AI 增值包或商业化实验前的推演。

2026-04-131

review-gates

lujuncheng1225-cloud/AI_Commercialization--Product-Management-skills

在正式交付前用结构化关口审查方案、文档或分析结果。适用于避免局部正确但整体跑偏、避免草率交付的场景。

2026-03-261

ai-feature-brief

lujuncheng1225-cloud/AI_Commercialization--Product-Management-skills

定义一个 AI 功能的用户任务、输入、输出、质量标准和 fallback。适用于把模糊 AI 点子整理成可讨论方案的场景。

2026-03-251

ai-feature-shaping

lujuncheng1225-cloud/AI_Commercialization--Product-Management-skills

把一个 AI 产品想法整理成问题定义、功能定义、评估方案和风险评审。适用于 roadmap 前的产品定义场景。

2026-03-251

conversion-funnel-diagnostic

lujuncheng1225-cloud/AI_Commercialization--Product-Management-skills

诊断转化漏斗的阶段、掉点、可能原因和下一步核查方向。适用于获客、激活或付费转化出问题的场景。

2026-03-251

llm-evaluation-plan

lujuncheng1225-cloud/AI_Commercialization--Product-Management-skills

为 AI 功能定义离线与线上评估方案，包括样本、指标和阻断阈值。适用于上线前需要明确质量标准的场景。

2026-03-251

name	task-decomposition
description	把一个较大的 PM、AI PM 或商业化任务拆成可快速验证的执行步骤。适用于任务过大、容易失控、需要先把执行顺序和检查点想清楚的场景。
type	component
best_for	["把大任务拆成小步骤","降低 PRD、评审或分析任务的失控风险","给 agent 或团队生成可执行计划"]
scenarios	["把一份复杂 PRD 写作任务拆成 30 分钟内可推进的步骤","把一次商业化诊断拆成若干可验证的小任务"]

Purpose / 用途

在真正执行前，先把大任务拆成一串足够小、足够清楚、每步都能检查的动作，避免“直接开做然后一路漂移”。

Key Concepts / 核心概念

Atomic Step Rule / 原子步骤规则

每一步都应该：

只解决一个主要问题
有清楚输出
完成后能立即检查是否过关

如果一个步骤完成后仍然不知道“算不算做完”，说明还不够小。

Risk-First Ordering / 风险优先排序

优先做：

能暴露方向错误的步骤
能减少后续返工的步骤
能显著影响方案选择的步骤

不要把最关键的不确定性留到最后。

Review Hook / 审查挂钩

好拆解不只是顺序清单，还要写出：

哪一步之后应该停下来复核
哪些结果会导致回退
哪些步骤可以并行，哪些必须串行

Application / 用法

## Task Decomposition

### Goal
[这次任务最终要交付什么]

### Assumptions
- [关键假设]

### Work Steps
1. [步骤]
   - Output: [产出]
   - Check: [如何判断过关]

2. [步骤]
   - Output: [产出]
   - Check: [如何判断过关]

### Review Points
- [在哪些节点复核]

### Stop / Rework Conditions
- [什么情况下暂停或返工]

Examples / 示例

好：

“先确认问题定义，再拆成功指标和范围，最后才写详细需求；每一步结束后都能检查是否过关。”

差：

“先写一版再慢慢改。”

Strong Example / 强样例

## Task Decomposition

### Goal
产出一份面向新用户 onboarding 改版的 PRD 草案，并能支持设计和工程进入细化讨论。

### Assumptions
- 当前最大问题发生在首次价值出现前
- 本轮先解决激活，不同时处理邀请后的协作问题

### Work Steps
1. 重新确认问题定义
   - Output: 一段明确的问题陈述
   - Check: 能回答“谁卡住、卡在哪、为什么现在要解决”

2. 拆出 success metrics 和 guardrails
   - Output: 1 个主指标 + 2-3 个配套指标
   - Check: 指标能支持 go / no-go 判断，而不只是观察

3. 收敛本轮 scope
   - Output: must-have / out-of-scope 清单
   - Check: 每个 must-have 都能解释它如何影响主指标

4. 写核心流程和需求
   - Output: PRD 主体
   - Check: 方案、范围、风险之间没有明显冲突

5. 做交付前复核
   - Output: 返工点或可交付结论
   - Check: 至少经过一次 fit / reasoning / integration 审查

### Review Points
- Step 1 后复核是否把方案误写成问题
- Step 3 后复核是否 scope 失控
- Step 5 后决定是否可直接交付

### Stop / Rework Conditions
- 如果问题定义无法支撑主指标，停止写 PRD，回到 discovery
- 如果 must-have 超过本轮资源上限，回到 scope 收敛

Common Pitfalls / 常见误区

步骤太大，一步里混了多个决策
只写动作，不写产出和检查点
明明存在高风险假设，却把验证放到最后

References / 关联项

../workshop-facilitation/SKILL.md
../problem-statement/SKILL.md
../prd-development/SKILL.md
../experiment-brief/SKILL.md