issue-decomposition
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:
More from troykelly/codex-skills
error-recovery
Use when encountering failures - assess severity, preserve evidence, execute rollback decision tree, and verify post-recovery state
28documentation-audit
Use when documentation drift is detected. Comprehensively audits codebase and creates/updates Swagger, features docs, and general documentation to achieve full sync.
21security-review
MANDATORY for security-sensitive code changes - OWASP-based security review with dedicated checklist, required before PR for auth, input handling, API, database, or credential code
16code-explorer
Use when asked to trace existing codepaths or explicitly asked to run the code-explorer subagent.
11code-simplifier
Use when asked to simplify recently changed code without changing behavior or explicitly asked to run the code-simplifier subagent.
9code-reviewer
Use when explicitly asked to run the code-reviewer subagent or when another skill requires the code-reviewer agent card.
7