一键在 Manus 中运行任何 Skill

goal-decomposition

星标0

分支0

更新时间2026年4月30日 09:30

Use when facing complex, vague, or large-scope tasks that need to be broken down into clear, actionable steps before execution. Triggers include multi-step features, unclear requirements, or goals that cannot be completed in one hour.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

devcxl

devcxl/self-skill-registry

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Goal Decomposition

Overview

将模糊、宏大的目标逐层拆解为清晰、具体、可执行的小任务，直到每一步都能在一小时内完成。

核心原则：拆到最后一层时，不需要再"想"，只需要"做"。

When to Use

触发条件：

任务目标模糊或宏大（如"优化系统性能"、"重构模块"）
预估完成时间超过 1 小时
不清楚"下一步该做什么"
任务涉及多个模块或系统
需要协调多个子任务

不适用场景：

单文件、单函数的简单修改
目标已足够清晰，可直接执行
纯粹的信息查询任务

Quick Reference

层级	描述	时间跨度
愿景/长期目标	最终想要达成的状态	年
阶段目标	必须经历的里程碑	月/季
具体目标	可量化的交付物	周
关键任务	完成目标必做的事项	天
可执行行动	30-60分钟内可完成	小时

分解流程

第 1 步：明确终极目标

必须包含三要素：时间 + 结果 + 状态

❌ 错误	✅ 正确
提升代码质量	2周内将测试覆盖率从 60% 提升到 80%
优化性能	3天内将 API 响应时间从 500ms 降到 100ms
重构模块	1周内将 UserService 拆分为 Auth 和 Profile 两个服务

第 2 步：反向拆解阶段目标

核心问题："要实现这个目标，必须经历哪几个阶段？"

目标：1周内将 UserService 拆分为 Auth 和 Profile 两个服务

阶段拆解：
1. 分析阶段：梳理 UserService 所有方法和依赖关系
2. 设计阶段：定义 Auth 和 Profile 的接口边界
3. 实施阶段：逐步迁移代码
4. 验证阶段：测试 + 回归

第 3 步：量化阶段目标

没有量化 = 无法管理

❌ 模糊	✅ 量化
熟悉代码	输出 UserService 的依赖关系图
写测试	为 Auth 模块编写 15 个单元测试
完成迁移	Profile 相关的 8 个方法全部迁移到新服务

第 4 步：拆成关键任务

核心问题："要完成这个阶段目标，必须做哪些事？"

阶段目标：输出 UserService 的依赖关系图

关键任务：
- 识别所有 public 方法
- 追踪每个方法的调用链
- 识别外部依赖（DB、缓存、第三方服务）
- 绘制依赖图

第 5 步：拆到可执行行动

判断标准：

能在 30-60 分钟内完成
不需要再思考"怎么做"

❌ 不合格	✅ 合格
分析代码	用 grep 找出所有调用 UserService.login() 的位置
写文档	在 docs/architecture.md 中添加 Auth 模块的接口说明
做测试	为 AuthService.validateToken() 编写 3 个边界测试

SMART 校验

每个分解后的目标都必须通过 SMART 校验：

原则	校验问题
S - Specific	目标是否足够具体？
M - Measurable	如何判断已完成？
A - Achievable	现有资源能否实现？
R - Relevant	是否与上级目标相关？
T - Time-bound	有没有明确期限？

Common Mistakes

错误	问题	修复
分解太粗	单个任务仍需 2+ 小时	继续拆分直到 < 1 小时
分解太细	产生大量 5 分钟的微任务	合并相关任务
跳过量化	无法判断进度	每个目标必须有可衡量标准
只分解第一层	后续步骤仍然模糊	递归分解到可执行层
忽略依赖关系	任务顺序错误导致阻塞	明确标注任务间的前置依赖

输出格式

分解完成后，使用以下格式输出任务清单：

## 目标：[具体目标，包含时间和可量化结果]

### 阶段 1：[阶段名称] (预计 X 天)
- [ ] 任务 1.1：[可执行行动] (30min)
- [ ] 任务 1.2：[可执行行动] (45min)
  - 依赖：任务 1.1

### 阶段 2：[阶段名称] (预计 X 天)
- [ ] 任务 2.1：[可执行行动] (1h)
  - 依赖：阶段 1 完成
...

核心心法

好的目标分解，让你每一刻只需要回答一个问题： "下一步，我该做什么？"

同仓库更多 Skills

同仓库

merge-old-history-before-hash

devcxl/self-skill-registry

将指定 commit（含）之前的 Git 历史压缩为一个新的根提交，再把之后的提交按顺序 cherry-pick 到新历史上。触发场景： - 用户说"把某个 hash 之前的历史合并成一个提交" - 压缩/折叠早期噪声提交，只保留近期增量历史 - 发布前整理仓库，生成"一个基线 + 后续增量提交"结构 - 清理历史再对外开源或归档不适用：含大量 merge commit 的复杂拓扑、多人共享且禁止 force push 的公共分支。

2026-05-140

skill-evaluator

devcxl/self-skill-registry

Evaluate Clawdbot skills for quality, reliability, and publish-readiness using a multi-framework rubric (ISO 25010, OpenSSF, Shneiderman, agent-specific heuristics). Use when asked to review, audit, evaluate, score, or assess a skill before publishing, or when checking skill quality. Runs automated structural checks and guides manual assessment across 25 criteria.

2026-05-140

oauth2-frontend-backend-separation

devcxl/self-skill-registry

Use when implementing OAuth2 login with frontend-backend separation, where frontend redirects to backend OAuth endpoint and receives JWT token via redirect

2026-05-140

nodejs-cli-aur-packager

devcxl/self-skill-registry

Package published npm CLI tools into Arch Linux AUR packages with reproducible npm tarball builds. Use when creating or updating PKGBUILD/.SRCINFO for a Node.js or TypeScript command-line package already published to npm, computing sha256 for npm tarballs, inspecting bin entries and postinstall scripts, generating wrapper scripts, or running makepkg verification. Triggers include: \u201c把 npm CLI 打包成 AUR\u201d, \u201c为 npm 包生成 PKGBUILD\u201d, \u201cupdate AUR package for Node.js CLI\u201d, \u201c生成 .SRCINFO\u201d, \u201ccompute sha256 for npm tarball\u201d.

2026-05-140

database-design

devcxl/self-skill-registry

Use when designing, reviewing, or optimizing MySQL database schemas — covering table structure design, fixed audit fields, status field conventions, time field type selection, unique constraints for idempotency, and index design principles with EXPLAIN guidance. Triggers: 在项目中设计、评审或优化 MySQL 表结构，需要统一固定字段、状态字段、时间字段、唯一约束与索引设计规范时。Also relevant for database schema review, SQL table creation, index optimization, database migration design, and multi-table relationship modeling.

2026-04-300

skill-compress

devcxl/self-skill-registry

当用户要求精简 skill、减少体积、提高命中率或拆分大 skill 时触发。勿用于业务代码、技术文档或插件实现。

2026-04-300

name	goal-decomposition
description	Use when facing complex, vague, or large-scope tasks that need to be broken down into clear, actionable steps before execution. Triggers include multi-step features, unclear requirements, or goals that cannot be completed in one hour.
version	1.0.0
compatibility	["opencode","claude-code","codex"]
tags	["doc"]
category	utilities
metadata	{"language":"cn","license":"MIT","author":"devcxl"}

Goal Decomposition

Overview

将模糊、宏大的目标逐层拆解为清晰、具体、可执行的小任务，直到每一步都能在一小时内完成。

核心原则：拆到最后一层时，不需要再"想"，只需要"做"。

When to Use

触发条件：

任务目标模糊或宏大（如"优化系统性能"、"重构模块"）
预估完成时间超过 1 小时
不清楚"下一步该做什么"
任务涉及多个模块或系统
需要协调多个子任务

不适用场景：

单文件、单函数的简单修改
目标已足够清晰，可直接执行
纯粹的信息查询任务

Quick Reference

层级	描述	时间跨度
愿景/长期目标	最终想要达成的状态	年
阶段目标	必须经历的里程碑	月/季
具体目标	可量化的交付物	周
关键任务	完成目标必做的事项	天
可执行行动	30-60分钟内可完成	小时

分解流程

第 1 步：明确终极目标

必须包含三要素：时间 + 结果 + 状态

❌ 错误	✅ 正确
提升代码质量	2周内将测试覆盖率从 60% 提升到 80%
优化性能	3天内将 API 响应时间从 500ms 降到 100ms
重构模块	1周内将 UserService 拆分为 Auth 和 Profile 两个服务

第 2 步：反向拆解阶段目标

核心问题："要实现这个目标，必须经历哪几个阶段？"

目标：1周内将 UserService 拆分为 Auth 和 Profile 两个服务

阶段拆解：
1. 分析阶段：梳理 UserService 所有方法和依赖关系
2. 设计阶段：定义 Auth 和 Profile 的接口边界
3. 实施阶段：逐步迁移代码
4. 验证阶段：测试 + 回归

第 3 步：量化阶段目标

没有量化 = 无法管理

❌ 模糊	✅ 量化
熟悉代码	输出 UserService 的依赖关系图
写测试	为 Auth 模块编写 15 个单元测试
完成迁移	Profile 相关的 8 个方法全部迁移到新服务

第 4 步：拆成关键任务

核心问题："要完成这个阶段目标，必须做哪些事？"

阶段目标：输出 UserService 的依赖关系图

关键任务：
- 识别所有 public 方法
- 追踪每个方法的调用链
- 识别外部依赖（DB、缓存、第三方服务）
- 绘制依赖图

第 5 步：拆到可执行行动

判断标准：

能在 30-60 分钟内完成
不需要再思考"怎么做"

❌ 不合格	✅ 合格
分析代码	用 grep 找出所有调用 UserService.login() 的位置
写文档	在 docs/architecture.md 中添加 Auth 模块的接口说明
做测试	为 AuthService.validateToken() 编写 3 个边界测试

SMART 校验

每个分解后的目标都必须通过 SMART 校验：

原则	校验问题
S - Specific	目标是否足够具体？
M - Measurable	如何判断已完成？
A - Achievable	现有资源能否实现？
R - Relevant	是否与上级目标相关？
T - Time-bound	有没有明确期限？

Common Mistakes

错误	问题	修复
分解太粗	单个任务仍需 2+ 小时	继续拆分直到 < 1 小时
分解太细	产生大量 5 分钟的微任务	合并相关任务
跳过量化	无法判断进度	每个目标必须有可衡量标准
只分解第一层	后续步骤仍然模糊	递归分解到可执行层
忽略依赖关系	任务顺序错误导致阻塞	明确标注任务间的前置依赖

输出格式

分解完成后，使用以下格式输出任务清单：

## 目标：[具体目标，包含时间和可量化结果]

### 阶段 1：[阶段名称] (预计 X 天)
- [ ] 任务 1.1：[可执行行动] (30min)
- [ ] 任务 1.2：[可执行行动] (45min)
  - 依赖：任务 1.1

### 阶段 2：[阶段名称] (预计 X 天)
- [ ] 任务 2.1：[可执行行动] (1h)
  - 依赖：阶段 1 完成
...

核心心法

好的目标分解，让你每一刻只需要回答一个问题： "下一步，我该做什么？"