| name | task-plan |
| description | This skill MUST be invoked when the user says "task-plan", "görev planla", "break down this PRD", "create tasks from spec", "PRD'yi parçala", "görevleri oluştur" or any variation requesting task breakdown from a specification document. SHOULD also invoke when user mentions "feature breakdown", "sprint planning", "task tracking", or wants to manage a structured development workflow with features and tasks.
|
| argument-hint | [PRD path | add <description> | status | run] |
Task Plan - Generate Task Breakdown from PRD
Analyzes PRD/SPEC files and creates/updates comprehensive task breakdown structures.
Supports subcommands: add, status, run.
Subcommands
| Command | Description |
|---|
/task-plan | Analyze PRD, generate/update tasks |
/task-plan docs/PRD.md | Specify PRD path |
/task-plan add "description" | Add a new feature inline |
/task-plan add @docs/spec.md | Add feature from file |
/task-plan status | Show task status table |
/task-plan run | Run all tasks autonomously |
Operating Mode
On each execution:
- PRD Analysis: Analyze the PRD file from scratch
- Check Current State: Read existing files in
tasks/ directory
- Detect Changes: Identify new features, changed requirements, or removed sections
- Incremental Update: Update only changed parts, preserve existing progress
Finding PRD File
- If provided as argument:
$ARGUMENTS
- Otherwise search project root:
PRD.md, SPEC.md, prd.md, spec.md, docs/PRD.md, docs/SPEC.md
Core Steps
Step 1: Find and Read PRD File
Search for PRD/SPEC in project root and docs/, specifications/, specs/ directories.
Step 2: Analyze Existing Task Structure
If tasks/ directory exists:
- Read all feature files (tasks/XXX-*.md)
- Read
tasks/tasks-status.md
- Record status of completed and in-progress tasks
- Track highest Feature ID (FXXX) and Task ID (TXXX) for continuation
When PRD is added to an existing project with manually added features, new features
must continue from the highest existing IDs. Never reset or conflict.
Step 3: Parse PRD and Compare
Extract: project metadata, feature boundaries, technical stack, user stories,
performance criteria, security requirements.
Compare with existing tasks:
- New features: In PRD but not in tasks/
- Changed features: Definition changed in PRD
- Removed features: In tasks/ but not in PRD (warn, don't delete)
Step 4: Create/Update Task Structure
For each new feature, create tasks/XXX-feature-name.md using the
feature template.
IMPORTANT RULES:
- Create 3-6 tasks per feature, each task should be 0.5-3 days of work
- Tasks should be atomic and independently testable
- Use realistic effort estimates based on complexity
- Dependencies MUST reference actual task IDs (T001, T002, etc.) or be "None"
- Do NOT use vague dependencies like "All backend features" or "Previous tasks"
- Success criteria must be specific and measurable
- Technical details should guide implementation
- Priority levels: P1=Critical, P2=High, P3=Medium, P4=Low
Rules for existing features:
- Preserve completed tasks (don't modify COMPLETED status)
- Preserve in-progress tasks (keep progress)
- Add new tasks for new requirements
- Mark changed requirements with AT_RISK status
Also update:
Step 5: Generate Change Summary
Output: added features, updated features, warnings (removed from PRD), statistics.
Task Properties Standards
Each task must include:
- Unique ID: TXXX format
- Status: NOT_STARTED | IN_PROGRESS | COMPLETED | BLOCKED | AT_RISK | PAUSED
- Priority: P1 (Critical) | P2 (High) | P3 (Medium) | P4 (Low)
- Effort: Developer-days (1 day = 6-8 hours)
- Dependencies: Hard and soft dependencies
- Success Criteria: At least 3-5 measurable criteria
- Files to Touch: File paths (new/update/delete)
Task sizing: Atomic tasks 0.5-5 days, Features 1-6 weeks, Milestones 1-3 months.
Subcommand Details
Quality Checklist
