---
name: planning-and-task-breakdown
description: "Decomposes specs into small, verifiable tasks with acceptance criteria and dependency ordering. Invoke when you have a spec and need implementable units, or when user says /plan. | 将规格分解为可验证的小任务，含验收标准和依赖排序。当有规格需要实现单元时，或用户说 /plan 时触发。"
metadata:
  {
    "builtin_skill_version": "1.0",
    "xingzierai":
      {
        "emoji": "📐",
        "requires": {}
      }
  }
---
# Planning and Task Breakdown

Transform specs into small, verifiable, independently testable tasks. Plan before you build.

## Overview

A spec without tasks is a wish list. This skill breaks down specs into actionable units that can be implemented, verified, and merged independently. Each task should be:
- **Small**: Can be completed in one session
- **Verifiable**: Has clear acceptance criteria
- **Independent**: Can be merged without other tasks
- **Valuable**: Provides incremental value

## When to Use

**Activate this skill when:**
- User says `/plan` or asks to "break down" or "plan" a feature
- A spec has been approved and needs implementation tasks
- Feeling overwhelmed by a large feature
- Multiple tasks seem blocked on each other
- Unclear what to work on next

**Do not activate for:**
- Already well-defined single tasks
- Quick fixes that don't need breakdown

## Process

### Step 1: List All Requirements

1. Read the `SPEC.md` thoroughly
2. Extract each functional requirement
3. List them as raw items (don't merge yet)

### Step 2: Identify Task Boundaries

For each requirement, ask:
- What is the **smallest unit** of work that adds value?
- What can be **implemented and tested independently**?
- What are the **dependencies** between tasks?

### Step 3: Create Tasks

Each task follows this template:

```markdown
## TASK-[N]: [Task Title]

**Requirement**: Which spec requirement this fulfills
**Type**: [feature | refactor | fix | infrastructure]
**Size**: [S (<1hr) | M (1-4hr) | L (4-8hr) | XL (>8hr)]

### Description
Brief description of what to do.

### Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2

### Dependencies
- Depends on: TASK-[X] (if any)
- Blocks: TASK-[Y] (if any)

### Files to Modify
- `path/to/file1`
- `path/to/file2`
```

### Step 4: Order by Dependency

1. Draw a dependency graph
2. Identify tasks with no dependencies (start here)
3. Order remaining tasks by dependency chain
4. Identify parallelizable tasks

### Step 5: Prioritize

1. **P0**: Must do before anything else (bootstrapping, core interfaces)
2. **P1**: Core functionality
3. **P2**: Important but not blocking
4. **P3**: Nice to have

### Step 6: Save the Plan

Create `PLAN.md`:

```markdown
# Implementation Plan

## Summary
Brief summary of the plan.

## Task Graph
[Tasks and their dependencies]

## Execution Order
1. TASK-1: ...
2. TASK-2: ...
3. ...

## Parallel Work
- [List of tasks that can run in parallel]
```

## Rationalizations

| Excuse | Rebuttal |
|--------|----------|
| "I'll just start coding" | Without a plan, you'll waste time on dead ends and forgotten dependencies. |
| "The task is too big to plan" | Large tasks need planning more, not less. Break it until it's manageable. |
| "Dependencies are obvious" | They aren't. Write them down to verify your assumptions. |
| "Planning slows me down" | Planning is a investment. 1 hour planning saves 10 hours of rework. |

## Red Flags

- Task is described as taking more than 8 hours
- Task has more than 3 dependencies
- No clear acceptance criteria for a task
- Tasks seem to have circular dependencies
- Priority not assigned

## Verification

**Evidence that task planning is working:**

- [ ] All tasks have clear acceptance criteria
- [ ] Dependencies are explicitly documented
- [ ] Tasks are ordered by dependency
- [ ] Each task is small enough to complete in one session
- [ ] Plan is saved in `PLAN.md`
