tranhieutt/planning-and-task-breakdown

Planning and Task Breakdown

Purpose

Prevents the agent from hallucinating huge "big bang" code changes that break the system. This skill forces the decomposition of complex requirements into granular, independently verifiable, and atomic units of work. It establishes a shared roadmap between the Agent and the User.

---

Workflow

1. Requirements Assessment

• Interpret the overall goal using Read on existing documentation or source code to understand current capabilities.
• Identify missing information and constraints.

2. Task Decomposition

• Break the overarching goal down into logical Phases.
• Inside each Phase, create granular Tasks.
• CRITICAL: Each task must be ATOMIC (handling exactly one logical change, UI update, or API route).

3. Dependency Mapping

• Organize the tasks sequentially. Ensure foundational setup tasks (e.g., Database Schema changes) occur strictly before dependent tasks (e.g., API creation or UI hooks).

4. Create the Plan & Request Approval

• Output the fully structured plan to the user.
• End by unequivocally asking for approval to start the first task.

---

Output Format

The output MUST use standard Markdown checklists.

# 🗺️ Implementation Plan: [Epic Name]

### Phase 1: [Phase Name - e.g., Foundation & Database]
- [ ] **Task 1.1**: [Atomic description - e.g., Create User migration]
- [ ] **Task 1.2**: [Atomic description - e.g., Update Prisma schema and seeders]

### Phase 2: [Phase Name - e.g., Backend API]
- [ ] **Task 2.1**: [Atomic description]

### Phase 3: [Phase Name - e.g., Frontend Integration]
- [ ] **Task 3.1**: [Atomic description]

---
**Status**: ⏸️ Awaiting plan approval. 
**Next Action**: Shall I execute *Task 1.1*?

---

Anti-Rationalizations

Be aware of lazy logic that an Agent typically uses to skip planning. If a thought on the left occurs, YOU MUST apply the rebuttal on the right:

| Excuse (Agent's Lazy Rationalization) | Rebuttal & Correct Action | | :--- | :--- | | "I can do this all in one step, it's just 5 files. Let me generate all the code right now." | REJECTED. Working on multiple interconnected files at once prevents isolated testing and makes rollbacks a nightmare. Break the files into separate tasks. | | "The user didn't ask for a plan, they just asked me to 'build the dashboard'." | REJECTED. Vague, large prompts are dangerous. Jumping straight to code guarantees structural drift. Present an explicit plan first to sync expectations. | | "Task 1 involves setting up the DB, API, and UI all at once so it works end-to-end." | REJECTED. That is an epic, not an atomic task. You must separate DB, API, and UI into different sequential tasks. |

---

Verification Gates

Do not conclude your first interaction turn unless you have fulfilled the following:

• [ ] The entire plan is laid out using Markdown checklists [ ].
• [ ] No single task encompasses more than 1 distinct architectural domain (e.g., DB and UI in the same task).
• [ ] You have paused the execution and explicitly requested user approval to proceed with Task 1.

---

Edge Cases

• [Vague Requirements]: If the user's initial prompt lacks the necessary detail to map out all phases (e.g., "build me a chat app"), create a Phase 1 called "Requirement Gathering" and ask 3 highly specific clarifying questions before attempting to map out Phases 2 and 3.

---

Related Skills

• spec-driven-development — Often used directly after planning to create a rigid technical specification for the currently active atomic task.
• test-driven-development — Used to execute the atomic tasks generated by this planning phase.