# Project Planning & Task Breakdown

> Yazılım geliştirme projeleri için detaylı planlama ve görev dağılımı (breakdown) yeteneği.

- Skill: `gktuoktay/project-planning-task-breakdown` (Agent Skill)
- Install (CLI): `npx skillmds@latest add gktuoktay/project-planning-task-breakdown`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gktuoktay/project-planning-task-breakdown/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: GktuOktay (https://skillmd.com/u/gktuoktay)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/gktuoktay/project-planning-task-breakdown

---


# Project Planning & Task Breakdown Skill

## Overview
This skill focuses on taking a high-level requirement or abstract idea and transforming it into a structured, actionable, and prioritized implementation plan. It covers task decomposition, dependency mapping, risk identification, and structured outputs for engineering execution.

## Phase 1: Requirements Analysis

Before breaking down tasks, establish absolute clarity on what needs to be built.
1. **Objective Statement**: What is the primary goal of this project?
2. **Scope Boundaries**: Explicitly define what is IN scope and what is OUT of scope.
3. **Success Criteria**: How will we know this project is completed successfully? (e.g., Performance metrics, user acceptance tests).

## Phase 2: Task Decomposition (The Hierarchy)

Break down the work into progressively smaller, manageable units.

1. **Epics (High-Level Features)**: Major functional areas (e.g., "User Authentication System").
2. **Stories (User-Centric Work)**: Specific functionality delivering value (e.g., "As a user, I can log in with Google").
3. **Tasks (Technical Implementation)**: Engineering steps to achieve a story (e.g., "Set up OAuth2 endpoints", "Create Login UI component").
4. **Subtasks (Checklist Items)**: Micro-steps (e.g., "Add Google logo asset", "Write unit tests for token validation").

*Rule of Thumb*: A Task should represent work that takes a single engineer 1-3 days to complete. If it takes longer, it should be broken down further.

## Phase 3: Dependency Mapping

Identify the order of operations to prevent blockers.
- **Finish-to-Start (FS)**: Task B cannot start until Task A finishes. (Most common in software).
- **Parallel Workstreams**: Identify which tasks can be developed concurrently by different team members (e.g., Frontend UI can be built with mock data while Backend API is being developed).

*Example Mapping*:
- Database Schema (Blocks ->) Backend API
- Backend API (Blocks ->) Frontend Integration
- UI Mockups (Blocks ->) Frontend Layout

## Phase 4: Risk Identification & Mitigation

Analyze potential failure points before coding begins.
- **Technical Risks**: Unproven technologies, third-party API rate limits, complex migrations.
- **Scope Risks**: Vague requirements, feature creep.
- **Mitigation Strategy**: For each high-risk item, define a mitigation (e.g., "Create a Spike/PoC for the third-party API integration before committing to the full architecture").

## Phase 5: Prioritization Frameworks

When scope exceeds time/resources, use prioritization.

### MoSCoW Method
- **Must Have**: Non-negotiable for the MVP.
- **Should Have**: Important, but not strictly necessary for launch.
- **Could Have**: Nice to have if time permits.
- **Won't Have**: Explicitly excluded from this phase.

### RICE Scoring (For Feature Selection)
- **Reach**: How many users does this affect?
- **Impact**: How much does it improve the experience?
- **Confidence**: How sure are we of our estimates?
- **Effort**: How long will it take? (Score = Reach * Impact * Confidence / Effort)

## Output Template: Implementation Plan

When generating a plan, use this structured artifact format:

```markdown
# Implementation Plan: [Project Name]

## 1. Executive Summary
- **Goal**: Brief description.
- **Out of Scope**: What we are explicitly NOT doing.

## 2. Technical Architecture/Approach
- Brief overview of technologies, frameworks, and architecture decisions.

## 3. Milestones & Task Breakdown

### Milestone 1: Foundation & Data Layer (Must Have)
*Goal: Set up database schemas and core abstractions.*
- [ ] **Task 1.1**: Define User schema (Dependency: None)
- [ ] **Task 1.2**: Setup DB migrations (Dependency: 1.1)

### Milestone 2: Core API & Logic (Must Have)
*Goal: Implement business logic and endpoints.*
- [ ] **Task 2.1**: Implement auth endpoints (Dependency: 1.2)
- [ ] **Task 2.2**: Write API integration tests (Dependency: 2.1)

### Milestone 3: Frontend & Integration (Should Have)
*Goal: Connect UI to the backend.*
- [ ] **Task 3.1**: Build login form components (Dependency: None - use mocks)
- [ ] **Task 3.2**: Connect login form to API (Dependency: 2.1, 3.1)

## 4. Identified Risks & Mitigations
- **Risk**: API Rate limits from provider.
- **Mitigation**: Implement caching layer early in Milestone 2.
```

## Conclusion
A good plan is not static; it is a living document. The goal of planning is to remove ambiguity, identify critical paths, and align engineering execution with product goals.