Token导航 LogoToken导航TokenDH.com
研究检索敏感数据github未标认证来源可访问许可证需确认审计通过

task-decomposition任务分解

Agent Skill

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

总安装

675

周安装

29

GitHub Stars

1

下载量

237
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 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

简介

task-decomposition 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。

  • 适用于任务分解相关的信息搜集与筛选,可结合来源仓库和原始 README 核验具体用法。
  • 通过 npx skills add 命令从指定 GitHub 仓库安装,需确认权限范围和维护状态。
  • 安装前建议确认是否会触发联网、命令执行或文件读写等操作边界。
  • 适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

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.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

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