1. 基本信息
| 项目 | 内容 | 数据来源 |
|---|---|---|
| 名称 | planning-and-task-breakdown | GitHub API / SKILL.md |
| 作者/维护者 | Addy Osmani（addyosmani/agent-skills 仓库所有者），外部协作者 hiyochi、ayobamiseun（Ayobami Adegoke）、nucliweb（Joan León，Google Developer Expert） |
GitHub API（commits） |
| 来源链接 | https://github.com/addyosmani/agent-skills/tree/main/skills/planning-and-task-breakdown | — |
| 许可证 | MIT | GitHub API |
| GitHub Stars / Forks | 所属仓库 80,789★ / 8,713 forks（该数字属整个 agent-skills 合集，不代表本技能个体热度，仅供了解所属仓库规模） | GitHub API |
| 最新版本 | 无独立版本号；所属仓库整体最新发布版 0.6.5（2026-07-26），该子技能自身最近一次内容提交为 2026-07-22 | GitHub API（releases / commits） |
| 安装方式 | Claude Code / Codex 原生插件市场一条命令安装，或 npx skills add 单独安装本技能（见第 10 章） |
仓库 README |
2. 功能介绍与亮点
planning-and-task-breakdown 把“拿到一份需求/spec 后如何拆成能落地的任务”这件事系统化成一份可执行指南，核心是先只读分析、再按依赖关系自底向上排序、最后按“垂直切片”（每个任务都交付一条完整可用的功能路径，而非先搭完所有数据库表、再搭完所有接口、最后才搭界面）组织任务。
核心能力：
- 只读规划阶段：编码前先分析 spec 与代码库，产出计划文档
tasks/plan.md与任务清单tasks/todo.md，规划阶段不允许写代码 - 依赖关系图：显式画出“数据库表→接口模型→接口实现→前端调用→界面”这类依赖链，实现顺序自底向上
- 垂直切片原则：反对“先建完所有表、再写所有接口、最后拼界面”的水平分层做法，改为每个任务交付一条完整可用路径
- 任务规格模板：每个任务需写明描述、可验证的验收标准、验证步骤（测试+人工检查）、显式依赖、规模估算（S/M/L/XL），并明确“L 及以上必须再拆分”
- 检查点机制：每完成 2–3 个任务设一个检查点，确认测试通过、构建成功、核心流程可跑通后再继续
- 常见借口对照表：针对“边做边想”“任务很明显不用写”等心理列出对应现实，帮助自查
亮点：纯 Markdown 无脚本执行；仓库把“验收标准”与项目级 references/definition-of-done.md（跨技能共享的“完成”标准清单）明确挂钩，形成“单任务验收标准 + 项目级完成基线”两层校验；该子目录已有三名可核实身份的外部协作者参与内容改进，其中一次提交专门修复了“计划文件被写到根目录而非 tasks/ 子目录”的实际行为缺陷。
3. 适用场景
固定分类：元技能与 Agent 增强
- 已有一份 spec 或明确需求，但不知道该按什么顺序拆成可执行任务的初中级开发者
- 单个任务感觉“太大不知道从哪下手”，需要先估算规模、拆到能一次专注会话内完成的粒度
- 需要在多个 agent 会话或多人之间并行推进工作、需要提前理清哪些任务能并行、哪些必须先后完成的场景
- 希望把“边做边想”改成“先写计划再执行”、减少大范围返工的用户
4. 跨 Agent 兼容性
- Claude Code：原生支持——仓库自带
.claude-plugin目录，可通过插件市场安装，也可用npx skills add直接放入.claude/skills/ - Codex：原生支持——仓库自带
.codex-plugin目录，README 明确说明可通过codex plugin marketplace add安装（需 Codex CLI v0.122+），安装后用@planning-and-task-breakdown调用 - OpenClaw：原生支持——技能安装 CLI（
vercel-labs/skills）官方支持列表明确列出 OpenClaw，对应路径skills/（项目级）/~/.openclaw/skills/（全局） - Hermes Agent：原生支持——同一份 CLI 官方支持列表明确列出 Hermes Agent，对应路径
.hermes/skills/（项目级）/~/.hermes/skills/（全局）
（基于已抓取的官方安装文档判断，未为兼容性单独发起搜索）
5. 推荐理由
初中级用户用 agent 写代码时最容易吃亏的地方之一，就是拿到一个大需求直接让 agent 一头扎进去写，结果中途才发现漏了依赖、任务越滚越大、最后还不知道怎么验收。planning-and-task-breakdown 用“先只读分析、再按依赖排序、再垂直切片”这套具体步骤，把“怎么拆任务”从凭感觉变成有章可循的流程，配套的规模分档与检查点机制能在任务失控前就发出信号，且已有真实第三方开发者验证并采纳了其中的分档规则。
6. 评分
| 维度 | 分数 | 说明 |
|---|---|---|
| 受欢迎程度 | 7 | 所属仓库整体 80,789★ 属于整个 agent-skills 合集，不代表本技能个体热度；该子目录自身有 3 名可核实身份的外部协作者提交改进（hiyochi 修复计划文件输出路径缺陷已合并、ayobamiseun 扩展跨生态命令写法已合并、nucliweb 即 Joan León——Google Developer Expert、1,237 名 GitHub 关注者的真实 Web 性能领域从业者——补充“完成定义”参考文档），另有独立第三方博客文章专门引用并实践了本技能的任务规模分档规则 |
| 可用性 | 9 | SKILL.md 单文件、零外部依赖，含依赖关系图示例、任务模板、规模分档表、常见借口对照表，结构完整；子目录最近一次内容提交为 2026-07-22，维护活跃；跨多个生态原生安装，无付费依赖 |
| 安全性 | 9 | 见下方检查清单 |
安全检查清单：
① 执行 shell 命令——技能本身不含可执行脚本，仅指导 agent 在只读分析阶段避免写代码，唯一的本地写操作是生成 tasks/plan.md、tasks/todo.md 两个 Markdown 文件
② 联网外发数据——技能内容为本地任务规划指导，不涉及技能自身向外部服务器发送数据
③ API key/凭据——不涉及，技能本身不要求任何密钥
④ 未发现可疑指令——抓取 SKILL.md 及其引用的 references/definition-of-done.md 全文，内容均为透明的任务拆解方法论，无混淆代码或隐蔽外发
⑤ 作者信誉——Addy Osmani 为公开可查的 Web 工程背景个人，该子目录有可核实身份的外部协作者共同参与，非匿名单人项目
⑥ License——MIT，明确
⑦ 维护时间——子目录最近一次提交 2026-07-22，仓库整体最近一次发版 2026-07-26，近期活跃
综合评分：8.33（三项均值，四舍五入至两位小数）
7. 跟同类 Skills 相比的优势
| 项目 | 定位 | 与 planning-and-task-breakdown 的差异 |
|---|---|---|
| planning-with-files（独立仓库） | 把计划持久化到磁盘三个文件，解决长会话上下文压缩/崩溃后“忘记之前决定”的问题 | 定位是“记忆续接”——关注计划如何在上下文清空后被找回；planning-and-task-breakdown 定位是“任务拆解”——关注一份 spec 该怎么拆成有依赖顺序、可验收的具体任务，两者可以先用后者拆任务、再用前者持久化执行进度 |
| GitHub Spec Kit（github/spec-kit，CLI 工具） | 独立脚手架工具，围绕 Specify/Plan/Tasks/Implement 四阶段命令组织整个项目工作流 | 定位是“独立工具链”——需要单独安装 CLI、按其脚手架结构组织项目；planning-and-task-breakdown 是单份 Markdown 技能，直接叠加在既有 agent 技能体系上，不需要额外工具链或项目结构改造 |
| code-simplification（同仓库另一子技能） | 聚焦已写好代码的复杂度削减 | 定位是“减负”——处理的是已经存在的代码；planning-and-task-breakdown 处理的是编码开始前的任务组织，两者分别对应“写之前”与“写之后”两个不同阶段 |
planning-and-task-breakdown 的差异化在于把“任务该怎么拆、按什么顺序做、多大算合适”这件事本身当作一份独立技能来对待，既不像 planning-with-files 那样解决的是记忆持久化问题，也不像 Spec Kit 那样要求额外安装一整套工具链，而是给 agent 一份可以直接叠加使用的拆解方法论。
8. 用户评价
- 来源：独立博客 rachel.fyi，作者 Rachel Cantor
- 内容摘要：文章专门引用了本技能“单个任务尽量控制在约 5 个文件以内”这一具体约束，作者自述实践中经常超出这个数字，但发现这条约束本身是有效的预警信号——一旦任务规模膨胀超过阈值，就会停下来判断是不是把多个任务混在了一起；作者还采纳了检查点机制，把计划文件当作“何时暂停复核”的约定来使用。
9. 其他补充
仓库同时提供 .agents、.gemini、.opencode 等多种生态适配目录，并通过第三方 CLI 工具 vercel-labs/skills 支持“70+ 智能体”的统一安装；README 将 24 个技能按 Define→Plan→Build→Verify→Review→Ship 生命周期分组，planning-and-task-breakdown 对应其中的 Plan 阶段，与 Define 阶段的 spec-driven-development、Build 阶段的 incremental-implementation 存在明确的前后衔接关系，任务验收标准还与项目级 references/definition-of-done.md 挂钩。
10. 安装使用方式
- Claude Code 插件市场：
/plugin marketplace add addyosmani/agent-skills，再执行/plugin install agent-skills@addy-agent-skills - Codex：仓库自带
.codex-plugin，可通过codex plugin marketplace add addyosmani/agent-skills安装，用@planning-and-task-breakdown调用 - 通用 CLI（含 OpenClaw / Hermes Agent）：
npx skills add addyosmani/agent-skills --skill planning-and-task-breakdown（仅安装该子技能，CLI 会按所选 agent 自动放入对应目录，如 OpenClaw 的skills/、Hermes Agent 的.hermes/skills/） - 本地开发：
git clone https://github.com/addyosmani/agent-skills.git，再用claude --plugin-dir /path/to/agent-skills加载
安装后无需重启，agent 拿到一份 spec 或较大需求时会自动触发该技能进行任务拆解；若只想要该技能而不装整套 24 个工程技能，建议用 CLI 的 --skill 参数单独安装。
11. 注意事项
- 该技能是纯方法论指导，不会自动生成或执行任务，仍需 agent 结合具体项目自行完成拆解与实现
- SKILL.md 中“See Also”引用的
references/definition-of-done.md位于仓库根目录而非本技能子目录内，若只单独复制skills/planning-and-task-breakdown/文件夹安装，需要额外手动获取该参考文件才能获得完整的验收基线上下文 - 仓库以整套工程技能包（24 个子技能）为主体发布，若通过插件市场整体安装会连带装入其余 23 个非本技能相关的子技能
- 规模分档（S/M/L/XL）与“单任务不超过约 5 个文件”均为经验性建议，不同技术栈、不同团队的合理阈值可能有所出入，需结合实际项目调整