agentsclimarketplace

Issue decomposition

Skill troykelly/claude-skills/skills/issue-decomposition

Use when an issue is too large for a single task - breaks into linked sub-issues with full documentation, ensuring manageable work unitsFrom its SKILL.md

Install
npx -y skills add troykelly/claude-skills --skill issue-decomposition

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 11 stars11 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.3 KB, ~1.3k tokens by cl100k_base, as published. Nobody here has run it

Issue Decomposition

Overview

Break large issues into manageable sub-issues. Each sub-issue should be completable in a single focused session.

Core principle: If an issue is too big, decompose it before starting work.

Announce at start: "I'm using issue-decomposition to break this large issue into manageable sub-tasks."

When to Decompose

An issue is too large when ANY of these are true:

IndicatorThreshold
Acceptance criteriaMore than 5 criteria
Areas touchedMore than 3 unrelated code areas
Estimated workMore than 1 context window
DeliverablesMultiple independent features
DependenciesComplex internal sequencing

When in doubt, decompose. Smaller issues are better than larger ones.

The Decomposition Process

Step 1: Analyze the Parent Issue

Read the issue thoroughly and identify:

  1. Independent work units - Things that can be done separately
  2. Dependencies - What must come before what
  3. Natural boundaries - Logical separation points
  4. Acceptance criteria groupings - Which criteria relate to each other

Step 2: Plan Sub-Issues

Create a decomposition plan:

## Decomposition Plan for #[PARENT_NUMBER]

### Sub-Issue 1: [Title]
**Criteria from parent:** 1, 2
**Dependencies:** None
**Deliverable:** [What this sub-issue delivers]

### Sub-Issue 2: [Title]
**Criteria from parent:** 3, 4
**Dependencies:** Sub-Issue 1
**Deliverable:** [What this sub-issue delivers]

### Sub-Issue 3: [Title]
**Criteria from parent:** 5
**Dependencies:** Sub-Issue 2
**Deliverable:** [What this sub-issue delivers]

Step 3: Create Sub-Issues

For each sub-issue:

gh issue create \
  --title "[Type] [Parent Title] - [Sub-Task Title]" \
  --body "## Description

Part of #[PARENT_NUMBER]: [Parent Title]

[Specific description of this sub-task]

## Acceptance Criteria

- [ ] [Criterion 1 - copied or derived from parent]
- [ ] [Criterion 2]

## Verification Steps

[How to verify this specific sub-task]

## Dependencies

- Requires: #[PREVIOUS_SUB_ISSUE] (if any)
- Blocks: #[NEXT_SUB_ISSUE] (if any)

## Parent Issue

Closes part of #[PARENT_NUMBER]"

Step 4: Label and Link

# Label sub-issues
gh issue edit [SUB_ISSUE_NUMBER] --add-label "sub-issue"

# Label parent
gh issue edit [PARENT_NUMBER] --add-label "parent"

Step 5: Update Parent Issue

Add to the parent issue body:

## Sub-Issues

This issue has been broken down into:

- [ ] #[SUB_1] - [Title]
- [ ] #[SUB_2] - [Title]
- [ ] #[SUB_3] - [Title]

Complete all sub-issues to resolve this parent issue.

Step 6: Add to Project

# Add all sub-issues to project
gh project item-add [PROJECT_NUMBER] --owner @me --url [SUB_ISSUE_1_URL]
gh project item-add [PROJECT_NUMBER] --owner @me --url [SUB_ISSUE_2_URL]
# etc.

# Set status to Ready (or Backlog if blocked)

Step 7: Update Memory

Store the decomposition in knowledge graph:

Entity: Issue [PARENT_NUMBER]
Observation: "Decomposed into sub-issues [X], [Y], [Z] on [DATE]"

Relations:
- Issue [PARENT] --has_sub_issue--> Issue [SUB_1]
- Issue [SUB_1] --blocks--> Issue [SUB_2]

Sub-Issue Quality Checklist

Each sub-issue MUST have:

  • Clear title indicating it's part of parent
  • Reference to parent issue in description
  • Own acceptance criteria (not just "see parent")
  • Own verification steps
  • Dependencies documented (if any)
  • Added to GitHub Project
  • Labeled as sub-issue

Handling Dependencies

When sub-issues have dependencies:

Dependency TypeProject StatusNotes
No dependenciesReadyCan start immediately
Blocked by another sub-issueBacklogMove to Ready when blocker completes
Blocks another sub-issueReadyWork on this first

After Decomposition

Once decomposition is complete:

  1. Update memory with decomposition record
  2. Return to Step 1 of issue-driven-development with first sub-issue
  3. Work through sub-issues in dependency order
  4. Close parent issue when all sub-issues are done

Example Decomposition

Parent Issue: #100 - Implement user authentication

Sub-Issues Created:

#TitleDependenciesCriteria
101Auth - Database schemaNoneUser table, session table
102Auth - Registration endpoint#101Signup, validation, storage
103Auth - Login endpoint#101Login, session creation
104Auth - Logout endpoint#103Session invalidation
105Auth - Protected route middleware#103Auth check, redirect
106Auth - UI integration#102, #103, #104, #105Forms, state, routing

Common Mistakes

MistakeCorrection
Sub-issues too vagueEach sub-issue needs specific, verifiable criteria
Missing dependenciesMap out order before creating sub-issues
Not updating parentParent must list all sub-issues
Skipping project setupEach sub-issue must be in project with correct status
Criteria duplicated wrongDerive specific criteria, don't just copy all

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most task breakdown skills give in ~1.3k tokens

Counted across 221 of the 230 authors here whose files we hold, read 2026-09-06

  • Write acceptance criteria for every taskin 32 of 221, across 30 files
  • Add checkpoints every two to three tasksin 18 of 221, across 16 files
  • Schedule high-risk tasks earlyin 16 of 221, across 14 files
  • Slice work vertically into complete feature pathsin 16 of 221, across 14 files
  • Include verification steps in every taskin 15 of 221, across 13 files
  • Map dependencies between componentsin 14 of 221, across 12 files
  • Get human approval before implementingin 14 of 221, across 12 files
  • Enter read-only plan mode before writing codein 10 of 221
  • Read the spec and codebase before planningin 9 of 221, across 7 files
  • Map the dependency graph before ordering tasksin 8 of 221
  • Break any task touching more than five filesin 8 of 221
  • List each task's dependenciesin 7 of 221

Said here and by no other author read

  • Decompose large issues before starting work
  • Analyze the parent for work units and dependencies
  • Label sub-issues and the parent
  • List all sub-issues in the parent issue
  • Add all sub-issues to the project
  • Set sub-issue status by dependency state

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.