Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

Começar

task-decomposition

Estrelas1

Forks0

Atualizado26 de março de 2026 às 05:18

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

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

lujuncheng1225-cloud

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

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Especialistas em gestão de projetosNegócios e Operações Financeiras·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

Mais deste repositório

mesmo repositório

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