Use when an issue is too large for a single task - breaks into linked sub-issues with full documentation, ensuring manageable work units
Breaks large issues into manageable sub-issues with full documentation and dependency tracking. Triggered when an issue exceeds 5 acceptance criteria, touches 3+ unrelated code areas, or requires more than one context window to complete.
/plugin marketplace add troykelly/claude-skills/plugin install issue-driven-development@troykelly-skillsThis skill is limited to using the following tools:
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."
An issue is too large when ANY of these are true:
| Indicator | Threshold |
|---|---|
| Acceptance criteria | More than 5 criteria |
| Areas touched | More than 3 unrelated code areas |
| Estimated work | More than 1 context window |
| Deliverables | Multiple independent features |
| Dependencies | Complex internal sequencing |
When in doubt, decompose. Smaller issues are better than larger ones.
Read the issue thoroughly and identify:
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]
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]"
# Label sub-issues
gh issue edit [SUB_ISSUE_NUMBER] --add-label "sub-issue"
# Label parent
gh issue edit [PARENT_NUMBER] --add-label "parent"
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.
# 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)
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]
Each sub-issue MUST have:
sub-issueWhen sub-issues have dependencies:
| Dependency Type | Project Status | Notes |
|---|---|---|
| No dependencies | Ready | Can start immediately |
| Blocked by another sub-issue | Backlog | Move to Ready when blocker completes |
| Blocks another sub-issue | Ready | Work on this first |
Once decomposition is complete:
issue-driven-development with first sub-issueParent Issue: #100 - Implement user authentication
Sub-Issues Created:
| # | Title | Dependencies | Criteria |
|---|---|---|---|
| 101 | Auth - Database schema | None | User table, session table |
| 102 | Auth - Registration endpoint | #101 | Signup, validation, storage |
| 103 | Auth - Login endpoint | #101 | Login, session creation |
| 104 | Auth - Logout endpoint | #103 | Session invalidation |
| 105 | Auth - Protected route middleware | #103 | Auth check, redirect |
| 106 | Auth - UI integration | #102, #103, #104, #105 | Forms, state, routing |
| Mistake | Correction |
|---|---|
| Sub-issues too vague | Each sub-issue needs specific, verifiable criteria |
| Missing dependencies | Map out order before creating sub-issues |
| Not updating parent | Parent must list all sub-issues |
| Skipping project setup | Each sub-issue must be in project with correct status |
| Criteria duplicated wrong | Derive specific criteria, don't just copy all |
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.