메뉴
Use when reviewed architecture or API contracts must be decomposed into implementation-ready work items, especially when sequencing, reversible brownfield increments, dependency mapping, and vertical slices must be explicit before coding begins.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when a bug, failing test, regression, or unexpected behavior needs a root-cause-first debugging loop before code changes, especially when brownfield seams, recent releases, or historical defect matches make guesswork unsafe.
Use when E2E tests must go beyond shallow happy-path checks — multi-step user journeys, stateful sessions, cross-boundary state consistency, failure-mode edges — or when the suite passes but production still breaks. Platform- and framework-agnostic (web, mobile, desktop; Playwright, XCUITest, Cypress).
Use when discovery has narrowed an idea enough that the team must make a go/no-go, pivot, or scope-down decision based on technical, economic, operational, or timeline viability before requirements, architecture, or major implementation.
The mandatory gateway for all new engineering work. Triage and route new products, apps, features, migrations, tech-debt, or any 'not sure where to start' request to the correct lifecycle path. Use before starting design or implementation. Do not use for ongoing tasks, specific debugging, or PR reviews.
Use when discovery needs evidence about market demand, competitors, pricing pressure, or underserved segments for a new product or expansion idea before feasibility, user research, or requirements are finalized.
Use when intake has identified the likely lifecycle path but the problem statement, solution direction, or key trade-offs are still too fuzzy for requirements, research, or architecture work to start cleanly
| name | pc-task-breakdown |
| description | Use when reviewed architecture or API contracts must be decomposed into implementation-ready work items, especially when sequencing, reversible brownfield increments, dependency mapping, and vertical slices must be explicit before coding begins. |
| metadata | {"phase":"03-planning","inputs":["architecture-doc","spec-doc","api-contract"],"outputs":["task-list","dependency-graph"],"prerequisites":["pc-system-design"],"quality_gate":"All tasks completable in 1-3 days, dependencies mapped, no orphan tasks","roles":["tech-lead","developer"],"methodologies":["all"],"effort":"medium"} |
Break big work into small, shippable pieces. If a task takes more than 3 days, it's not broken down enough.
Task breakdown turns architecture and specs into actionable work items.
See context and anti-pattern notes.
I/O contract notes define required inputs and authority.
From the architecture, identify major work areas:
For brownfield work, identify work packages around reversible seams, coexistence adapters, compatibility boundaries, and characterization/regression safety rather than assuming replacement-only implementation.
Each task should be:
Pattern: [Verb] [noun] [context]
Where possible, decompose into vertical slices that preserve user-visible or contract-visible value instead of layer-only sequences.
Identify which tasks must complete before others can start:
Visualize as a DAG (directed acyclic graph) to identify critical path and parallelism opportunities.
Flag tasks that are blocked by unresolved upstream questions. Do not hide those blockers inside optimistic sequencing.
Each task has explicit "done" criteria:
Order tasks to:
When the work is modernization or migration:
Produce only declared outputs at their documented quality boundary.
