一键导入
issue-decomposition
Use when an issue is too large for a single task - breaks into linked sub-issues with full documentation, ensuring manageable work units
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when an issue is too large for a single task - breaks into linked sub-issues with full documentation, ensuring manageable work units
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use before starting ANY work - hard gate ensuring a GitHub issue exists, creating one if needed through user questioning
Use when receiving UAT feedback, bug reports, user testing results, stakeholder feedback, QA findings, or any batch of issues to investigate. Investigates each item BEFORE creating issues, classifies by type and priority, creates well-formed GitHub issues with proper project board integration.
MANDATORY for all work - the project board is THE source of truth. This skill provides verification functions and gates that other skills MUST call. No work proceeds without project board compliance.
Use for LARGE work requiring feature-level grouping. Creates epic tracking issues, manages related issues under a common label, tracks epic progress, and coordinates with milestones.
Use when the user wants to design Codex agent equivalents (specialized workers/profiles/prompt files), define triggering conditions, or build reusable agent prompts and validation tools.
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.
| name | issue-decomposition |
| description | Use when an issue is too large for a single task - breaks into linked sub-issues with full documentation, ensuring manageable work units |
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 |