Token导航 LogoToken导航

Agent Skill · 研究检索

task-decomposition(任务分解)

task-decomposition 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

task-decomposition 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为接触敏感数据;许可证信息还不明确,第三方扫描已通过,按安装量在研究检索类的 73,675 个 Skill 里排第 48,806。

总安装 675周安装 29GitHub Stars 1下载 237核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:task-decomposition(任务分解)
来源仓库:https://github.com/pixel-process-ug/superkit-agents
仓库路径:skills/task-decomposition
安装命令:
npx skills add https://github.com/pixel-process-ug/superkit-agents --skill task-decomposition
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/pixel-process-ug/superkit-agents --skill task-decomposition

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

task-decomposition 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。适用于任务分解相关的信息搜集与筛选,可结合来源仓库和原始 README 核验具体用法。

通过 npx skills add 命令从指定 GitHub 仓库安装,需确认权限范围和维护状态。安装前建议确认是否会触发联网、命令执行或文件读写等操作边界。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

来源仓库内路径:skills/task-decomposition

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/pixel-process-ug/superkit-agents --skill task-…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要接触敏感数据,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

task-decomposition 怎么安装?

在终端执行 npx skills add https://github.com/pixel-process-ug/superkit-agents --skill task-decomposit…。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

task-decomposition 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

task-decomposition 需要什么权限?

权限级别是接触敏感数据。该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

task-decomposition 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

task-decomposition 用的人多吗?

公开数据是累计安装 675 次,近一周安装 29 次,下载 237 次,GitHub 1 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

task-decomposition 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 需要接触敏感数据,装到常用环境前要先评估影响面。
  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 环境里有大量密钥、凭证,不方便给第三方 Skill 读取的人。
  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
task-decomposition

任务分解 · 本页

6751接触敏感数据未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Task Decomposition

Overview

Task decomposition breaks complex tasks into manageable, well-defined subtasks with clear dependencies, effort estimates, and parallelization opportunities. It covers hierarchical work breakdown structures (WBS), dependency graph construction, critical path analysis, task sizing, and identification of concurrent execution opportunities. Essential for planning multi-step implementations, project estimation, and autonomous loop task selection.

Announce at start: "I'm using the task-decomposition skill to break this work into a structured hierarchy with dependencies and estimates."

Trigger Conditions

  • Complex task needs to be broken into subtasks
  • Dependency mapping is needed between work items
  • Effort estimation is required for planning
  • Parallelization opportunities need to be identified
  • /decompose command invoked
  • Transition from planning skill for complex plans
  • Autonomous loop needs task selection guidance

Phase 1: Scope Definition

Goal: Define clear boundaries for the decomposition.

  1. Define the overall deliverable and acceptance criteria
  2. Identify the boundaries (what is in scope, what is not)
  3. Determine the decomposition granularity level
  4. Identify stakeholders and their requirements
  5. Establish constraints (time, resources, dependencies)

Granularity Decision Table

ContextTarget LevelTypical DurationRationale
Autonomous loop (Ralph)L3-L4 (Task/Subtask)15 min - 4 hoursONE task per loop iteration
Sprint planningL2-L3 (Story/Task)0.5-2 daysSprint-sized work items
Roadmap planningL0-L1 (Epic/Feature)2-8 weeksHigh-level milestone tracking
Bug fixL3-L4 (Task/Subtask)15 min - 2 hoursFocused, specific fixes

Granularity Levels

LevelNameTypical DurationExample
L0Epic2-8 weeks"User authentication system"
L1Feature2-5 days"OAuth2 login flow"
L2Story0.5-2 days"Google OAuth provider integration"
L3Task1-4 hours"Implement Google callback handler"
L4Subtask15-60 minutes"Parse OAuth token response"

STOP — Do NOT proceed to Phase 2 until:

  • Deliverable and acceptance criteria are defined
  • Scope boundaries are clear (in/out)
  • Target granularity level is chosen
  • Constraints are identified

Phase 2: Hierarchical Breakdown

Goal: Decompose the work into a tree structure meeting the INVEST criteria.

  1. Identify top-level work streams (epics or major components)
  2. Break each work stream into features or milestones
  3. Decompose features into implementable tasks
  4. Apply the "2-hour rule" — no task should exceed 2 hours of focused work
  5. Ensure each task has a clear definition of done
  6. Verify MECE (Mutually Exclusive, Collectively Exhaustive) coverage

The INVEST Criteria for Tasks

CriterionQuestionBad ExampleGood Example
IndependentCan this be done without waiting for others?"Implement auth after DB is ready""Implement auth with mock DB"
NegotiableIs the approach flexible?"Use Redis for caching""Add caching layer for user sessions"
ValuableDoes completing this deliver value?"Set up folder structure""Create user registration endpoint"
EstimableCan you estimate the effort?"Improve performance""Add database index for user lookup query"
SmallCan one person finish it in < 2 hours?"Build the dashboard""Create dashboard chart component for revenue data"
TestableCan you verify it is done?"Make it better""Response time < 200ms for /api/users"

MECE Verification

CheckQuestion
Mutually ExclusiveDoes any task overlap with another? (Should not)
Collectively ExhaustiveDo all tasks together cover the full deliverable? (Should)
No orphansDoes every task contribute to the deliverable?
No gapsIs there any work needed that has no task?

STOP — Do NOT proceed to Phase 3 until:

  • All work streams are identified
  • Tasks meet INVEST criteria
  • MECE coverage is verified
  • No task exceeds 2 hours

Phase 3: Dependency Mapping

Goal: Build a directed acyclic graph (DAG) of task dependencies.

  1. Identify input/output dependencies between tasks
  2. Classify dependency types
  3. Build a directed acyclic graph (DAG)
  4. Identify the critical path (longest dependency chain)
  5. Flag circular dependencies as errors to resolve
  6. Mark external dependencies (API access, approvals, third-party)

Dependency Types

TypeSymbolMeaningExample
Finish-to-Start (FS)A -> BB cannot start until A finishes"Deploy" after "Build passes"
Start-to-Start (SS)A => BB can start when A starts"Write docs" when "Write code" starts
Finish-to-Finish (FF)A =>> BB cannot finish until A finishes"Testing" finishes after "Development"
Start-to-Finish (SF)A ~> BB cannot finish until A startsRare — shift handoff scenarios

Dependency Notation Format

Task 1: Set up database schema
Task 2: Create data access layer         [depends: 1]
Task 3: Implement API endpoints          [depends: 2]
Task 4: Write unit tests for DAL         [depends: 2]
Task 5: Write API integration tests      [depends: 3, 4]
Task 6: Create frontend components       [depends: none]
Task 7: Connect frontend to API          [depends: 3, 6]
Task 8: End-to-end testing               [depends: 5, 7]

Parallel tracks:
  Track A: 1 -> 2 -> 3 -> 5 -> 8
  Track B: 1 -> 2 -> 4 -> 5 -> 8
  Track C: 6 -> 7 -> 8
  Critical path: 1 -> 2 -> 3 -> 7 -> 8

Circular Dependency Resolution

DetectionResolution
A depends on B, B depends on ABreak into smaller tasks that remove the cycle
A depends on B's interface, B depends on A's interfaceDefine interfaces first as a separate task
Tight coupling between componentsIntroduce an abstraction layer task

STOP — Do NOT proceed to Phase 4 until:

  • All dependencies are mapped
  • No circular dependencies exist
  • Critical path is identified
  • External dependencies are flagged

Phase 4: Parallelization Planning

Goal: Identify independent task clusters that can run concurrently.

  1. Identify independent task clusters (no dependencies between them)
  2. Group tasks by resource type (read, write, build, test)
  3. Determine maximum parallelism based on resource constraints
  4. Sequence tasks within each parallel track
  5. Plan synchronization points (merge gates)

Resource-Based Parallelism Limits

Resource TypeMax ParallelRationale
Code reading / analysisUnlimitedNo side effects
File creation / editing3-5Avoid merge conflicts
Build / compile1Resource contention
Test execution1-2Shared state, ports
Database migrations1Sequential by nature
DocumentationUnlimitedIndependent files

Parallelization Pattern Decision Table

PatternWhen to UseExample
Independent ClustersWork streams with no shared stateBackend, Frontend, Infra
By LayerLayers touch different filesAPI, Service, Data
By Feature AreaIndependent vertical slicesAuth, Profile, Billing
By Task TypeCode, tests, docs touch different filesImplement, Test, Document

Synchronization Points

  +------+     +------+     +------+
  |Task A|     |Task B|     |Task C|
  +--+---+     +--+---+     +--+---+
     |            |            |
     v            v            v
  ======================================
     SYNC GATE: All Complete
     Verify: no conflicts, tests pass
  ======================================
                 |
                 v
          +----------+
          |Next Phase|
          +----------+

STOP — Do NOT proceed to Phase 5 until:

  • Independent clusters are identified
  • Resource constraints are considered
  • Synchronization points are defined
  • Maximum parallelism is determined

Phase 5: Estimation and Prioritization

Goal: Estimate effort for each task and create an execution timeline.

T-Shirt Sizing to Hours

SizeHoursConfidenceExample
XS0.5-1hHighRename a variable, fix a typo
S1-2hHighAdd a simple endpoint, write a test
M2-4hMediumImplement a feature with known pattern
L4-8hLowNew feature with research needed
XL8h+Very LowMust be decomposed further

Estimation Heuristics

ScenarioMultiplierRationale
Known pattern1.2x base estimate20% buffer for unknowns
Unknown pattern2x base estimateAdd research spike task first
Integration work1.5x sum of componentsIntegration is harder than parts
First-time technology3x "if I knew how" estimateLearning curve
Bug fixesTime-box 2h investigationThen re-estimate

Three-Point Estimation

Expected = (Optimistic + 4 * Most Likely + Pessimistic) / 6

Example:
  Optimistic:  2 hours (everything goes smoothly)
  Most Likely: 4 hours (normal development pace)
  Pessimistic: 10 hours (major unexpected issues)
  Expected:    (2 + 16 + 10) / 6 = 4.7 hours

Prioritization Decision Table

FactorWeightHow to Evaluate
On critical pathHighestDelays here delay everything
Blocks other tasksHighUnblocking multiplies throughput
Business valueHighUser-facing impact
Risk reductionMediumDe-risks unknowns early
Quick winMediumLow effort, high morale
Nice to haveLowOnly after core work is done

Work Breakdown Structure Template

# WBS: [Project Name]

## 1. [Work Stream A]
### 1.1 [Feature]
- [ ] 1.1.1 [Task] — Est: 2h — Deps: none — Priority: P0
- [ ] 1.1.2 [Task] — Est: 1h — Deps: 1.1.1 — Priority: P0
- [ ] 1.1.3 [Task] — Est: 3h — Deps: 1.1.1 — Priority: P1

### 1.2 [Feature]
- [ ] 1.2.1 [Task] — Est: 1h — Deps: none — Priority: P0
- [ ] 1.2.2 [Task] — Est: 2h — Deps: 1.2.1, 1.1.2 — Priority: P1

## 2. [Work Stream B]
### 2.1 [Feature]
- [ ] 2.1.1 [Task] — Est: 1h — Deps: none — Priority: P0
- [ ] 2.1.2 [Task] — Est: 4h — Deps: 2.1.1 — Priority: P0

## Summary
- Total tasks: N
- Estimated total effort: Xh
- Critical path duration: Yh
- Max parallelism: Z tracks
- External dependencies: [list]

Critical Path Analysis

How to Find the Critical Path

  1. List all tasks with durations and dependencies
  2. Forward pass: calculate earliest start (ES) and earliest finish (EF)
  3. Backward pass: calculate latest start (LS) and latest finish (LF)
  4. Float = LS - ES (tasks with zero float are on the critical path)
  5. The critical path is the longest chain through the dependency graph

Optimization Strategies

StrategyWhenEffectRisk
ParallelizeIndependent tasks on critical pathReduces calendar timeLow
Fast-trackOverlap sequential tasksReduces durationMedium — may cause rework
CrashAdd resources to critical tasksReduces durationMedium — coordination cost
Scope reductionRemove non-essential tasksReduces total workLow — if non-essential is correct
Spike firstUnknown tasks blocking the pathDe-risks estimatesLow

Anti-Patterns / Common Mistakes

Anti-PatternWhy It FailsCorrect Approach
Tasks too large to estimate"Build the backend" is not a taskDecompose until estimable (< 2h)
Missing dependenciesSurface during implementation, cause reworkMap ALL dependencies upfront
Circular dependenciesIndicate unclear architectureBreak the cycle with interface tasks
All tasks sequentialNo parallelism possibleIdentify independent clusters
Estimation without decompositionGuessing at L0 level, always wrongEstimate at leaf level, sum up
Ignoring external dependenciesBlock progress unexpectedlyFlag and plan for them
Over-decompositionNoise, not signal (50 subtasks for a form)Stop at meaningful, testable units
Ignoring critical pathPriorities work on non-critical tasksAlways prioritize critical path
Not re-estimatingEstimates drift as you learnRe-estimate after each phase
Tasks without acceptance criteriaCannot verify completionEvery task has definition of done

Anti-Rationalization Guards

If you catch yourself thinking:

  • "I can estimate the whole thing without breaking it down..." — No. Decompose first.
  • "Dependencies are obvious, I don't need to map them..." — Map them. Hidden dependencies cause failures.
  • "This task is fine at 8 hours..." — Decompose it. XL tasks must be broken down.
  • "The critical path doesn't matter for small projects..." — It does. It tells you what to prioritize.

Subagent Dispatch Opportunities

Task PatternDispatch ToWhen
Parallelizable leaf tasks identified during decompositionParallel subagents via Agent toolWhen tasks have no shared dependencies
Architecture analysis of task boundariesplanner agentWhen decomposition reveals cross-cutting concerns
Validation of decomposition completenessspec-reviewer agentWhen task tree is complete but unverified

Mark each decomposed task with a parallelizable: yes/no flag in the output table. Follow the dispatching-parallel-agents skill protocol when dispatching.


Integration Points

SkillRelationshipWhen
planningUpstream — provides the plan to decomposeComplex plans need WBS
task-managementDownstream — receives decomposed tasksFor execution tracking
dispatching-parallel-agentsDownstream — receives parallelizable clustersFor concurrent execution
autonomous-loopDownstream — task selection from WBSRalph task selection
executing-plansDownstream — batch creation from WBSPlan execution
subagent-driven-developmentDownstream — independent tasks for subagentsDelegated implementation
spec-writingComplementary — specs inform decompositionUnderstanding requirements

Concrete Examples

Example: Decomposition of "Add User Authentication"

# WBS: User Authentication

## 1. Core Auth
### 1.1 Token Management
- [ ] 1.1.1 Implement JWT generation — Est: 1h — Deps: none — P0
- [ ] 1.1.2 Implement JWT validation — Est: 1h — Deps: 1.1.1 — P0
- [ ] 1.1.3 Implement refresh token rotation — Est: 2h — Deps: 1.1.2 — P1

### 1.2 Auth Middleware
- [ ] 1.2.1 Create auth middleware — Est: 1h — Deps: 1.1.2 — P0
- [ ] 1.2.2 Add role-based access control — Est: 2h — Deps: 1.2.1 — P1

## 2. Auth Endpoints
### 2.1 Registration
- [ ] 2.1.1 POST /auth/register endpoint — Est: 1h — Deps: 1.1.1 — P0
- [ ] 2.1.2 Email validation — Est: 30m — Deps: none — P0

### 2.2 Login
- [ ] 2.2.1 POST /auth/login endpoint — Est: 1h — Deps: 1.1.1, 1.2.1 — P0
- [ ] 2.2.2 POST /auth/refresh endpoint — Est: 1h — Deps: 1.1.3 — P1

## Summary
- Total tasks: 8
- Estimated total effort: 10.5h
- Critical path: 1.1.1 -> 1.1.2 -> 1.2.1 -> 2.2.1 (4h)
- Max parallelism: 3 tracks (Token, Middleware, Endpoints)
- External dependencies: none

Skill Type

RIGID — Follow the decomposition phases in order. Every task must meet the INVEST criteria and have explicit dependencies, estimates, and acceptance criteria. The dependency graph and critical path analysis are mandatory for multi-day work.

平台分布

Codex

36.6%
按下载量换算87

Claude

28.03%
按下载量换算66

Cursor

19.42%
按下载量换算46

Gemini CLI

8.78%
按下载量换算21

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

接触敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills