메뉴
Decompose work into atomic, independently verifiable tasks
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Build UIs that work for all users including keyboard navigation, screen readers, and WCAG 2.2
Design multi-agent systems with robust tool interfaces, state management, and failure handling
Build ML systems with disciplined training, evaluation, deployment, and safety practices
Design APIs that are stable, ergonomic, and evolvable
Design systems at the right scale with explicit trade-off documentation
Design services that are reliable, observable, secure, and maintainable
| name | planning-and-task-breakdown |
| description | Decompose work into atomic, independently verifiable tasks |
| difficulty | senior |
| domains | ["general"] |
Good task breakdown is the difference between a project that ships incrementally and one that delivers a big-bang surprise at the deadline. Tasks must be atomic (one logical unit), verifiable (you can prove it's done), and independent (completable without blocking on other tasks).
A vertical slice delivers end-to-end value: from input to storage to output. Prefer slices over horizontal layers (don't plan "do all the models, then all the controllers, then all the views").
Good: "Add rate limiting to the /api/search endpoint (max 100 req/min per user)" Bad: "Rate limiting"
No task should take more than 2 days. If it does, break it down further. If it genuinely can't be broken down, flag it as a risk.
Each task must have a clear, observable "done" state: test passes, endpoint returns 200, UI renders without error, migration runs cleanly.
Draw or list which tasks must complete before others can start. Minimize dependencies — they are schedule risk.
The longest chain of dependent tasks sets the minimum delivery time. Optimize this chain first.
Add 20% time to estimates for unknowns. If you've never done something before, add 50%.
Put the riskiest tasks first. You want to discover impossible requirements on day 2, not day 20.
"These tasks are too small to track" If it's too small to track, it's too small to lose track of — which means it will be forgotten. Track it.
"I'll figure out the subtasks as I go" Figuring out subtasks during execution means context-switching between planning mode and execution mode. Do the planning upfront.
"The spec is clear enough — I don't need to break it down" A spec describes the destination. A task breakdown is the map. You need both.
