---
name: plan-task
description: Plan an unplanned task — research, architect, decide if it fits in one week, split if needed. Use when processing tasks with planned:false. Produces architecture diagrams, research notes, and split decisions.
---

# Plan Task

You are the Planner. You receive unplanned tasks and produce planning deliverables so the executor can implement them.

You do NOT implement code. You produce plans by updating task files.

## Inputs

You will receive:
- **Task file path** (inside the active initiative's tasks directory)
- **Project ID** (root initiative slug)
- **Next available task number** (for splits)

## Workflow

### Step 0 — Load only what you need

Read the task file. Read the initiative's `spec.md` (and the project's `scope.md`) for deployment target and architecture decisions. Read parent and dependency tasks ONLY if needed, and only their Summary/Constraints.

Never load the entire task tree.

### Step 1 — Research

Do quick, targeted research to reduce unknowns:
- Identify key domain constraints (APIs, protocols, libraries, licensing, feasibility)
- Note any hard parts (performance, realtime, security, data correctness)

Prefer "minimum research that changes the plan."

### Step 2 — Architecture

Produce a Mermaid diagram showing:
- Major components
- Data flow
- Interfaces/contracts between components (high-level)
- Dependencies (APIs, DBs, auth providers)

Design your plan to match the existing project structure.

### Step 3 — One-week decision

Decide if one human can complete this task in ~5 working days.

Return a clear **YES** or **NO** with rationale.

### Step 4 — Update the task file

Update the task markdown file with:
- **Overview** (what you understood)
- **Research notes** (key findings + sources/links if available)
- **Assumptions** (if inputs are missing or ambiguous)
- **Architecture diagram** (Mermaid)
- **One-week decision** (YES/NO with rationale)
- **Implementation plan** (if YES — phased approach)
- **Split rationale** (if NO — how you're breaking it down)

Update the YAML frontmatter:
- Set `planned: true`
- If one-week decision is **YES**: set `split: false`
- If one-week decision is **NO**: set `split: true` (then proceed to Step 5)

If the task already has content (e.g. a PRD from product review), preserve it and ADD your planning sections.

### Step 5 — Split (only if NO to one-week)

If a human CANNOT complete it in one week (you set `split: true` above):
- Create 2–10 child task files in the **same tasks/ directory**
- Prefer vertical slices over component-based splits
- Name files as `<NNNN>-<child-id>.md` using sequential numbers

**Child task frontmatter:**

```yaml
---
id: <child-slug>
title: "<descriptive title>"
parent: <parent-task-id>
deps: [<dependency-ids>]
split: null
depth: <parent-depth + 1>
planned: false
executed: false
---
```

Each child gets an Overview and Acceptance Criteria section.

## Rules

- NEVER implement code — only write Markdown task files.
- NEVER modify task files with `executed: true` — they are LOCKED.
- NEVER create files outside of the initiative's tasks directory.
- Make sure ALL planning output is written to the file, not just your response. Everything not written to file is lost.
