Menu
项目经理专属的任务拆解方法论。项目立项骨架完成后,或者项目阶段性补待办时,把项目目标按岗位拆成 3-5 条可执行的 deliverable,每条带 acceptance_criteria,挂到具体承担人身上。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | task_breakdown |
| description | 项目经理专属的任务拆解方法论。项目立项骨架完成后,或者项目阶段性补待办时,把项目目标按岗位拆成 3-5 条可执行的 deliverable,每条带 acceptance_criteria,挂到具体承担人身上。 |
| version | 1.0.0 |
| platforms | [] |
项目经理专属 skill。只有承担"项目经理"或"项目骨架拆解"职责的实例应当使用。 普通执行者不需要拆别人,只拆自己手上的待办(那是
todo_planningskill 的事)。
sense_project_detail 确认 cfg.manager == 你的 iid)不满足任何一条 → 沉默 rest,让经理来。
反例: "这个 6 个月项目我现在就把 30 条 task 全列出来" → 一定会过度规划,执行 1 周后发现 25 条都错了,白拆。
正解: 一次拆到能让第一个里程碑动起来的最小集合 —— 3-5 条 starter deliverable。 后续靠项目 review 时滚动补 todo(详见 "下次什么时候再拆" 段)。
没有"完成标准"的 deliverable 不是 deliverable,是模糊愿望。 拆之前自己先回答:这条做完了长什么样?能看到什么具体的东西?
每个 position(岗位)拆 1-2 条 starter。如果发现一个岗位需要 5 条起步 → 说明你岗位定义本身有问题(可能漏了一个隐藏的执行角色),回去调 positions。
每个 deliverable 用 project_todo create 时 type 字段建议:
execution → 直接执行 todo,模型自己跑(todo_execution skill)research → 先研究产出文档(todo_planning skill)design → 设计/规划,产出方案 / 图review → review 别人的产出这能让承担者收到的 todo 自带执行路径。
sense_project_detail("{pid}") # 看 goal / KPI / positions
sense_project_todos("{pid}") # 看现有 deliverable
回答自己 3 个问题:
按"做完这 3-5 条能让项目动起来"的最小集去定。
举例(一个原型渲染项目,架构师 + 开发者 + 产品):
5 条以内。done。剩下的等执行 2-3 天后再拆。
project_todo(
action="create",
project_id="{pid}",
title="{岗位}: {一句话具体描述}",
description="{展开 2-3 行,挂验收标准以外的上下文}",
acceptance_criteria="{完成标准 — 能看到什么具体产出}",
assignee_instance="{该岗位承担者 UUID}", // 必填! 找不到 UUID 就 sense_projects 先查
assignee_position="{岗位 id, 如 developer}",
priority="{low/medium/high/urgent}",
)
每个岗位建 1-2 条。
骨架里有 1 条 项目分工 todo(type=task_breakdown)分给你(manager)。
完成拆解后把它标 in_progress / done:
project_todo(action="update",
project_id="{pid}",
deliverable_id="{分工骨架 todo id}",
status="in_progress", // 表示拆解进度
)
全部拆完后 → 标 done。
express_to_human(
"@所有人 🔧 项目「{name}」首批 {N} 条执行 todo 已拆好,按岗位分配:
👤 @architect → 「理解原型 + 制定规范」
👤 @developer → 「环境准备」 / 「第一页渲染走通」
👤 @product → 「确认验收标准」
各位 sense_project_tos 查看自己的 todo,acceptance_criteria 都在里头。shift + 答复开始执行 → ~2-3 天后我 review 下一批。",
chat_id="{群 id}"
)
跟每条 deliverable 上的 acceptance_criteria 字段配合:承担者看到 todo 时就知道完成标准。
不要无脑定时拆。让信号触发:
| 信号 | 拆解动作 |
|---|---|
| 现有 todo 全部 in_progress 或 done,KPI 还有距离 | 拉起本 skill 拆下一批 |
| 某岗位 80% todo done | 给那个岗位补新 todo |
| KPI 偏离 / 论断验证失败 | 召集 review → 调整 → 拆新一批 |
| 新实例加入项目 | 给新实例拆 1-2 条 starter |
| 每周三 review 时 | 这是常规 review,顺带看是否要拆 |
任何时刻如果发现"rem 没用 拆的事" → 不要硬拆,等下个信号。
❌ 一次拆 20 条:会过度规划,执行中死字段会长出来,白拆 ❌ 不填 acceptance_criteria: 承担者没法判断 done,只能凭感觉 ❌ 不传 assignee_instance:todo 没人接,堆积成 dead pile ❌ type 空到底: 承担者收 todo 不知道"该研究还是直接做", 慢一周才反应 ❌ 把 todo 自己直接做掉: 你是经理,不是执行者,拆完要交付给承担者
拆完一批,自检:
全 ✓ → express 通知 + 休息等 review。任一 ✗ → 改。
早晨的整体审视与规划。从已有 portfolio 出发，按"角色 × 项目 × 来龙去脉"逐件深度思考，再整合成今日整体安排。
主动中段。在主线待办被推进的过程中，决定"接着推/转向/补刀"——而不是"想点事随便做做"。
待办执行的思考方法论。面对一个该做的待办时，怎么判断下一步、怎么推进、何时算收束、卡了怎么办。
晚间集中复盘。把一天散落的灵感、警告、卡点收集起来，对工作方式本身做一次诚实重构，然后写明日 jump-in。
每日记忆整理。梦境式的内部清理 + 合并 + 收敛,保持记忆系统「能用」而非「堆着」。
项目立项与骨架搭建——创建新项目（含默认分工 + 3 条骨架 todo）。不再做任务拆解细节，拆解交由 task_breakdown skill 由项目经理单独负责。当用户说"开个新项目"或收到 project_created 事件时调用。