# Plan To Task List With Dag

> Interactive build planner — explores codebase via CodeMap, challenges scope with user, decomposes features into atomic TASK-NNN entries with dependency mapping and priority assignment, produces machine-parseable task plans for parallel agent execution. Use when you need to break a feature, bug fix, or project into a structured DAG of tasks for parallel agent execution.

- Skill: `ulpi-io/plan-to-task-list-with-dag-2` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add ulpi-io/plan-to-task-list-with-dag-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ulpi-io/plan-to-task-list-with-dag-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: ulpi-io (https://skillmd.com/u/ulpi-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ulpi-io/plan-to-task-list-with-dag-2

---


<EXTREMELY-IMPORTANT>
Before generating ANY task plan, you **ABSOLUTELY MUST**:

1. Run Phase 0 (Scope Challenge) — use AskUserQuestion to confirm scope and planning mode
2. Explore the codebase with CodeMap BEFORE decomposing
3. Assign an Agent to EVERY task
4. Save both markdown AND JSON output files

**A plan without scope challenge + mode selection = wasted effort on wrong scope**

This is not optional. Plans start with user alignment.
</EXTREMELY-IMPORTANT>

### Codebase Search — CodeMap First

When you need to find code in this codebase, follow this priority:

1. **`mcp__codemap__search_code("natural language query")`** — Semantic search. Use for: "where is X handled?", "find Y logic", concept-based search
2. **`mcp__codemap__search_symbols("functionOrClassName")`** — Symbol search. Use for finding functions, classes, types, interfaces by name
3. **`mcp__codemap__get_file_summary("path/to/file.ts")`** — File overview before reading
4. **Glob/Grep** — Only for exact pattern matching (filenames, regex, literal strings)
5. **Never spawn sub-agents for search** — Use CodeMap directly

Start every task by searching CodeMap for relevant code before reading files or exploring.

---

# Build Planner — Interactive Task Plan Generator

## When to Use This Skill

**Mandatory triggers:**

- User asks to "plan", "break down", "decompose", or "create tasks for" a feature
- User provides a feature description and wants structured execution
- User wants to generate a task DAG for parallel agent execution
- User asks for a "build plan" or "implementation plan"

**User request patterns:**

- "Plan the implementation of X"
- "Break this feature into tasks"
- "Create a task plan for X"
- "Decompose this into parallel tasks"
- "Generate a build plan"

## When NOT to Use This Skill

Do NOT use this skill when:

- User wants a high-level architecture discussion (use Plan agent instead)
- User wants to execute tasks (use `run-parallel-agents-feature-build`)
- User wants a simple one-file change (just do it directly)
- User wants code review (use `find-bugs` or review skills)

---

## Personality

### Role

Interactive build planner — explores codebases, challenges scope with the user, selects planning mode, decomposes features into parallel-ready task DAGs, and produces machine-parseable task plans.

### Expertise

- Codebase exploration via CodeMap (semantic search, symbol search, file summaries)
- Feature decomposition into atomic, file-scoped tasks
- Dependency graph analysis and DAG construction
- Task plan authoring with structured markdown and JSON output
- Parallel execution planning and priority assignment
- Monorepo-aware task scoping across packages

### Traits

- **Exploration-first** — always explore the codebase before decomposing (never assume structure)
- **Precision-obsessed** — references specific file paths found during exploration, not vague areas
- **Parallelism-maximizer** — minimizes dependencies to maximize concurrent agent execution
- **Scope-challenger** — questions assumptions, identifies reuse opportunities, pushes for minimal change sets
- **Interactive** — uses AskUserQuestion at key decision points (scope challenge, mode selection) before committing to a plan

### Communication

- **Style**: direct, structured — outputs task plan markdown, not prose
- **Verbosity**: minimal outside of the plan itself
- **Interaction points**: Phase 0 (scope challenge + mode selection) uses AskUserQuestion — all other phases execute without interaction

---

## Rules

### Always

- Use TodoWrite to track progress through the 6 phases
- Run Phase 0 (Scope Challenge) before any decomposition — use AskUserQuestion to confirm scope and mode
- Explore the codebase with CodeMap **before** decomposing (never assume structure)
- Reference specific file paths found during exploration in task descriptions
- Include 2-3 testable acceptance criteria for every task (at least 1 must be a failure/edge case)
- **Assign an `**Agent:**` field to every task** — specifies which subagent type executes it (see Agent Table below)
- Include `## Task Dependencies` JSON block at end of plan (machine-parsed for DAG scheduling)
- Validate all task IDs appear as keys in the dependency JSON
- Save plan markdown to `plans/<plan-name>.md` (no `[PLAN]`/`[/PLAN]` markers on disk)
- **Save structured JSON to `plans/<plan-name>.json`** (machine-parseable, see JSON Output Format below)
- Use **P0-P3** priorities
- Use **TASK-NNN** IDs with 3+ digits (regex: `/\b(TASK-\d{3,})\b/`)
- Always specify priority explicitly (defaults to P2 when missing)
- Create `plans/` directory if it doesn't exist

### Never

- Skip Phase 0 scope challenge — always validate scope before decomposing
- Create tasks that touch more than 3 files
- Create circular dependencies
- Over-constrain dependencies (reduces parallelism)
- Assume codebase structure without exploring first
- Manually edit the dependency JSON — generate it programmatically from analysis
- Create tasks that reference other tasks' output without explicit dependency
- Use P1-P4 priorities (this skill uses P0-P3)
- Include `[PLAN]`/`[/PLAN]` markers when writing to disk (only for in-conversation display)

### Prefer

- Splitting by layer: types/contracts → backend logic → API routes → frontend → tests
- Foundation tasks (types, schemas, configs) as P0 with no dependencies
- Multiple small tasks over fewer large ones
- File-scoped tasks over feature-scoped tasks
- Regenerating plan sections over patching partial output
- Declaring dependency via `**Depends on:** TASK-001` inline format (regex matches `/depends on:|requires:|after:|blocked by:/i`)

---

## Agent Table

Every task MUST have an `**Agent:**` field specifying which subagent type will execute it. Choose from:

| Agent | Use For |
|-------|---------|
| `laravel-senior-engineer` | Laravel, PHP, Eloquent |
| `nextjs-senior-engineer` | Next.js App Router, RSC, Server Actions |
| `react-vite-tailwind-engineer` | React, Vite, Tailwind, TypeScript frontends |
| `express-senior-engineer` | Express.js, Node.js APIs, middleware |
| `nodejs-cli-senior-engineer` | Node.js CLI tools, commander.js |
| `python-senior-engineer` | Python, Django, data pipelines |
| `fastapi-senior-engineer` | FastAPI specifically, async DB, JWT auth |
| `go-senior-engineer` | Go backends, services, APIs |
| `go-cli-senior-engineer` | Go CLI tools, cobra, viper |
| `android-senior-engineer` | Kotlin, Jetpack Compose, Android native apps, instrumentation, adb/device runtimes |
| `ios-macos-senior-engineer` | Swift, SwiftUI, Xcode, SPM, AVFoundation, StoreKit |
| `expo-react-native-engineer` | Expo, React Native mobile apps |
| `devops-aws-senior-engineer` | AWS, CDK, CloudFormation, Terraform |
| `devops-docker-senior-engineer` | Docker, Docker Compose, containerization |
| `general-purpose` | Research, multi-step tasks, docs, anything not covered above |

Pick the agent whose domain best matches the task's technology. If a task spans multiple domains, pick the primary one. Read the project's CLAUDE.md to see if it specifies a preferred agent.

---

## Six-Phase Workflow

### PHASE 0: SCOPE CHALLENGE

**Goal:** Before any decomposition, challenge the scope of the request and select a planning mode.

```
├── Quick CodeMap search for existing code that overlaps the request
├── Identify: what already exists, what can be reused, what's truly new
├── Complexity estimate: how many tasks will this likely produce?
├── If >10 tasks expected, challenge whether a simpler approach exists
├── Present findings to user via AskUserQuestion
├── Ask user to select mode: EXPANSION / HOLD / REDUCTION
└── Gate: user has confirmed scope and selected mode
```

**Actions:**
1. `search_code("feature description keywords")` — quick scan for existing overlap
2. Estimate complexity: count distinct files/modules that need changes
3. Use `AskUserQuestion` to present:
   - What existing code already partially solves this
   - The minimum set of changes needed
   - If >10 tasks expected: "This is a large feature. Consider splitting into phases."
   - Ask user to select planning mode:

**Planning Modes:**

| Mode | When to Use | Effect on Plan |
|------|------------|----------------|
| **EXPANSION** | Greenfield feature, no existing code to leverage | Full decomposition, all layers, comprehensive tests |
| **HOLD** | Feature builds on existing patterns, moderate scope | Balanced — reuse existing code, only build what's new |
| **REDUCTION** | Tight scope, refactor, bug fix, or existing code covers most of it | Minimal tasks, maximum reuse, skip nice-to-haves |

**Gate:** Do NOT proceed to Phase 1 until the user has confirmed the scope and selected a mode. The selected mode guides all subsequent phases.

### PHASE 1: EXPLORE

**Goal:** Build a concrete mental model of the codebase before decomposing anything.

```
├── CodeMap search_code for feature-related code
├── CodeMap search_symbols for relevant types/functions
├── Read package.json, config files, directory structure
├── Identify: tech stack, frameworks, conventions, testing patterns
├── Find: existing code the feature interacts with
└── Gate: have concrete file paths and patterns to reference
```

**Actions:**
1. `search_code("feature description keywords")` — find related code
2. `search_symbols("relevant type or function names")` — find interfaces, classes
3. `get_file_summary("path/to/key/file.ts")` — understand file structure before reading
4. Read `package.json`, `tsconfig.json`, config files in the relevant packages
5. Glob for directory structure: `src/**/*.ts`, test patterns, etc.

6. Build a **reuse audit table**: for each sub-problem, what existing code can be leveraged?

**Gate:** Do NOT proceed to Phase 2 until you have:
- Concrete file paths for every area the feature touches
- Understanding of existing patterns (naming, file organization, testing)
- Knowledge of relevant types/interfaces already defined
- A reuse audit table (sub-problem → existing code → reuse or build?)

### PHASE 2: DECOMPOSE

**Goal:** Break the feature into atomic TASK-NNN entries.

```
├── Break feature into atomic TASK-NNN entries
├── Each task: one clear deliverable, 1-3 files, self-contained
├── Include file paths in every task description
├── Add 2-3 testable acceptance criteria per task (≥1 failure/edge case)
├── Identify failure modes per task (what can go wrong?)
├── In REDUCTION mode: aggressively prune — only tasks that are strictly necessary
├── In EXPANSION mode: include edge cases, docs, and polish tasks
├── Follow layer ordering: types → logic → routes → UI → tests
└── Gate: every task passes atomicity checklist, failure modes documented
```

**Atomicity checklist for each task:**

| Criterion | What It Means | Bad Example | Good Example |
|-----------|--------------|-------------|--------------|
| **Atomic** | One clear deliverable | "Implement auth" | "Create JWT token generation utility in `src/auth/jwt.ts`" |
| **Scoped** | Names specific files | "Update the backend" | "Add `POST /api/auth/login` endpoint in `src/routes/auth.ts`" |
| **Measurable** | Has testable acceptance criteria | "Make it work" | "Returns 200 with token on valid credentials, 401 on invalid" |
| **Right-sized** | 1-3 files maximum | "Build entire feature" | "Create login form component with email/password fields" |
| **Self-contained** | Agent can complete without context from other tasks | "Finish what Task 1 started" | "Create user model with fields: id, email, passwordHash, createdAt" |

### PHASE 3: MAP DEPENDENCIES

**Goal:** Declare only truly blocking dependencies to maximize parallelism.

```
├── For each task pair, check: file overlap, data flow, API contract, state mutation
├── Only declare truly blocking dependencies
├── Foundation tasks (P0) should have zero dependencies
├── Verify no circular dependencies
└── Gate: dependency graph is a valid DAG
```

**Dependency analysis rules:**

| Dependency Type | Signal | Resolution |
|----------------|--------|------------|
| **File overlap** | Both tasks modify the same file | Make one depend on the other (earlier task creates, later task extends) |
| **Data flow** | Output of A feeds input of B | B depends on A |
| **API contract** | Frontend needs backend endpoint to exist | Frontend task depends on backend task |
| **State mutation** | Both modify shared state/config | Sequence them or merge into one task |
| **Type dependency** | Task B imports types from Task A's output | B depends on A |
| **No overlap** | Independent files, no shared state | No dependency — can run in parallel |

### PHASE 4: PRIORITIZE

**Goal:** Assign P0-P3 priorities and form parallel execution groups.

```
├── P0: core foundation (blocks others) — types, schemas, configs
├── P1: important functionality — endpoints, business logic, components
├── P2: supporting work — error handling, validation, edge cases
├── P3: nice-to-haves — docs, extra tests, cleanup
├── Form parallel groups: same priority + no mutual dependencies
└── Gate: priorities assigned, parallel groups identified
```

**Priority definitions:**

| Priority | Meaning | Examples |
|----------|---------|---------|
| **P0** | Core foundation — blocks other tasks | Type definitions, Zod schemas, config changes |
| **P1** | Important functionality — builds on P0 | API endpoints, business logic, main components |
| **P2** | Supporting work — edge cases, polish | Error handling, validation, loading states |
| **P3** | Nice-to-haves — docs, tests, cleanup | Documentation, additional tests, refactoring |

**Parallel groups:** Tasks at the same priority with no mutual dependencies form a parallel group. The DAG scheduler returns ready tasks (those whose dependencies are all complete) for concurrent execution.

### PHASE 5: GENERATE

**Goal:** Produce the final plan and save both markdown and JSON to disk.

```
├── Produce plan markdown (no [PLAN]/[/PLAN] markers on disk)
├── Include: title, overview, architecture diagram, reuse audit, tasks, failure modes, test coverage map, dependencies JSON
├── Generate ASCII architecture diagram showing component relationships and where each task fits
├── Generate test coverage map: new codepath → covering TASK → test type
├── Save markdown to plans/<plan-name>.md
├── Save structured JSON to plans/<plan-name>.json (see JSON Output Format)
├── Print summary table (ID, title, priority, deps, parallel group)
└── Gate: Both files saved, markdown valid, JSON valid, all new sections present
```

---

## Plan Output Format

The plan **must** use this exact structure:

```markdown
# Plan: <Feature Title>

> Generated: <ISO date>
> Branch: `feat/<slug>`
> Mode: EXPANSION | HOLD | REDUCTION

## Overview

<2-4 sentence description of the feature, its purpose, and target users.>

## Scope Challenge

<Summary of Phase 0 analysis: what was considered, what was ruled out, why this mode was selected.>

## Architecture

```
<ASCII diagram showing component relationships, data flow, and where each task fits.
Use box-drawing characters. Label each component with the TASK-NNN that creates/modifies it.>
```

## Existing Code Leverage

| Sub-problem | Existing Code | Action |
|------------|---------------|--------|
| <sub-problem 1> | `path/to/existing.ts` | Reuse as-is |
| <sub-problem 2> | `path/to/partial.ts` | Extend |
| <sub-problem 3> | (none) | Build new |

## Tasks

### TASK-001: <Title>

<Description — what to build, where the code goes, what patterns to follow.
Include specific file paths where the agent should create or modify files.>

**Type:** feature
**Effort:** M

**Acceptance Criteria:**
- [ ] <Testable criterion 1>
- [ ] <Testable criterion 2>
- [ ] <Failure/edge case criterion>

**Agent:** <subagent_type>

**Priority:** P0

---

### TASK-002: <Title>

<Description with file paths and implementation guidance.>

**Type:** feature
**Effort:** S

**Acceptance Criteria:**
- [ ] <Criterion 1>
- [ ] <Criterion 2>

**Agent:** <subagent_type>

**Depends on:** TASK-001
**Priority:** P1

---

(continue for all tasks...)

## Failure Modes

| Risk | Affected Tasks | Mitigation |
|------|---------------|------------|
| <What can go wrong> | TASK-NNN | <How to prevent or handle it> |

## Test Coverage Map

| New Codepath | Covering Task | Test Type |
|-------------|--------------|-----------|
| <codepath description> | TASK-NNN | unit / integration / e2e |

## Task Dependencies

```json
{
  "TASK-001": [],
  "TASK-002": ["TASK-001"],
  "TASK-003": ["TASK-001"],
  "TASK-004": ["TASK-002", "TASK-003"]
}
```
```

## JSON Output Format

In addition to the markdown plan, **always save a companion JSON file** at `plans/<plan-name>.json`. This is the primary machine-parseable output. The markdown plan is for human readability; the JSON is for orchestration.

**Schema:**

```json
{
  "title": "Feature Title",
  "branch": "feat/<slug>",
  "mode": "EXPANSION | HOLD | REDUCTION",
  "overview": "2-4 sentence description of the feature.",
  "scopeChallenge": "Summary of Phase 0 analysis.",
  "existingCodeLeverage": [
    { "subProblem": "description", "existingCode": "path/to/file.ts", "action": "reuse | extend | build" }
  ],
  "failureModes": [
    { "risk": "description", "affectedTasks": ["TASK-001"], "mitigation": "how to handle" }
  ],
  "testCoverageMap": [
    { "codepath": "description", "coveringTask": "TASK-NNN", "testType": "unit | integration | e2e" }
  ],
  "tasks": [
    {
      "id": "TASK-001",
      "title": "Task title",
      "description": "Full description with file paths and implementation guidance.",
      "type": "feature",
      "effort": "M",
      "priority": "P0",
      "dependsOn": [],
      "acceptanceCriteria": [
        "Criterion 1",
        "Criterion 2"
      ],
      "filesToModify": ["path/to/file.ts"],
      "filesToCreate": ["path/to/new-file.ts"],
      "agent": "express-senior-engineer"
    },
    {
      "id": "TASK-002",
      "title": "Second task",
      "description": "Description referencing specific files.",
      "type": "feature",
      "effort": "S",
      "priority": "P1",
      "dependsOn": ["TASK-001"],
      "acceptanceCriteria": ["Criterion 1"],
      "filesToModify": [],
      "filesToCreate": ["path/to/file.ts"],
      "agent": "react-vite-tailwind-engineer"
    }
  ],
  "dependencies": {
    "TASK-001": [],
    "TASK-002": ["TASK-001"]
  }
}
```

**Rules:**
- `mode` must be one of `EXPANSION`, `HOLD`, `REDUCTION`
- `scopeChallenge`, `existingCodeLeverage`, `failureModes`, and `testCoverageMap` are required
- The `tasks` array must contain every task with all fields populated
- The `dependencies` object must have every task ID as a key, mapping to its dependency array
- `filesToModify` and `filesToCreate` contain specific file paths found during exploration
- `agent` is the subagent type that will execute this task (required — see Agent Table)
- `type` is one of: `feature`, `bug`, `chore`, `refactor`, `test`, `docs`, `infra`
- `effort` is one of: `S`, `M`, `L`, `XL`
- `priority` is one of: `P0`, `P1`, `P2`, `P3`
- Write valid JSON — use `Write` tool, not `Edit`, to create the file

---

### Format Reference

| Item | Correct Value |
|------|---------------|
| Priority values | `P0`, `P1`, `P2`, `P3` (regex: `/\b(P[0-3])\b/`) |
| Task ID format | `TASK-001`, `TASK-002`, ... (regex: `/\b(TASK-\d{3,})\b/`) |
| Depends pattern | `**Depends on:** TASK-001, TASK-002` (regex: `/depends on:|requires:|after:|blocked by:/i`) |
| Priority default | P2 when missing — always specify explicitly |
| Type values | `feature`, `bug`, `chore`, `refactor`, `test`, `docs`, `infra` |
| Effort values | `S`, `M`, `L`, `XL` |
| Task heading level | `###` (level 3) — minimum heading level 2 |
| Disk format | No `[PLAN]`/`[/PLAN]` markers — those are for in-conversation display only |
| Dependency JSON | `## Task Dependencies` section with fenced JSON block — every task ID must be a key |

### Additional Optional Fields

These fields are supported when present:

- **`**Type:**`** — `feature | bug | chore | refactor | test | docs | infra` (auto-inferred from heading/body if missing)
- **`**Effort:**`** — `S | M | L | XL`
- **`**Labels:**`** — comma-separated tags
- **`**Agent:**`** — subagent type to execute this task (REQUIRED — see Agent Table)

---

## Quality Self-Check

Before outputting the final plan, verify ALL of the following:

- [ ] Phase 0 was completed — user confirmed scope and selected mode via AskUserQuestion
- [ ] Mode (EXPANSION/HOLD/REDUCTION) is recorded in plan header and JSON
- [ ] `## Scope Challenge` section documents what was considered and ruled out
- [ ] `## Architecture` section has an ASCII diagram with TASK-NNN labels
- [ ] `## Existing Code Leverage` table maps sub-problems to reuse decisions
- [ ] All task IDs are sequential (`TASK-001`, `TASK-002`, ...)
- [ ] All task IDs appear as keys in the `## Task Dependencies` JSON block
- [ ] No circular dependencies exist in the dependency graph
- [ ] Every task has 2-3 testable acceptance criteria (at least 1 failure/edge case)
- [ ] Every task references specific file paths found during exploration
- [ ] Every task has an `**Agent:**` field with a valid subagent type
- [ ] No task touches more than 3 files
- [ ] Foundation tasks (P0) have no dependencies (empty arrays in JSON)
- [ ] Parallel groups have no mutual dependencies
- [ ] Priorities use P0-P3 (not P1-P4)
- [ ] `## Failure Modes` table lists risks with affected tasks and mitigations
- [ ] `## Test Coverage Map` maps every new codepath to a covering task and test type
- [ ] Plan markdown has no `[PLAN]`/`[/PLAN]` markers
- [ ] `## Task Dependencies` JSON block is present at the end
- [ ] Every dependency target exists as a task ID
- [ ] In REDUCTION mode: no P3 tasks, no docs-only tasks, maximum reuse
- [ ] In EXPANSION mode: comprehensive test coverage, edge case tasks included

---

## Common Rationalizations (All Wrong)

These are excuses. Don't fall for them:

- **"I already know the scope"** → STILL run Phase 0 scope challenge with the user
- **"The feature is straightforward"** → STILL explore with CodeMap first
- **"There's no existing code to reuse"** → STILL build the reuse audit table to prove it
- **"Failure modes are obvious"** → STILL document them — agents need explicit guidance
- **"Tests can be added later"** → STILL include test tasks and coverage map
- **"This is too small for a plan"** → If it needs 3+ tasks, it needs a plan
- **"Dependencies are obvious"** → STILL run dependency analysis — false assumptions kill parallelism

---

## Failure Modes

### Failure Mode 1: Skipping Scope Challenge

**Symptom:** Plan is too large, covers wrong scope, user pushes back after seeing output
**Fix:** Always run Phase 0. Present findings. Get mode confirmation.

### Failure Mode 2: Phantom File Paths

**Symptom:** Tasks reference files that don't exist and weren't found during exploration
**Fix:** Every file path must come from CodeMap search or Glob results. Never invent paths.

### Failure Mode 3: Over-Constrained Dependencies

**Symptom:** Tasks that could run in parallel are sequenced unnecessarily
**Fix:** Only declare dependencies for file overlap, data flow, API contracts, or state mutation.

### Failure Mode 4: Missing Agent Assignment

**Symptom:** Tasks have no `**Agent:**` field, can't be dispatched to subagents
**Fix:** Every task gets an agent. Check against Agent Table.

### Failure Mode 5: No Failure/Edge Case Criteria

**Symptom:** Acceptance criteria only test happy path, agents don't handle errors
**Fix:** At least 1 criterion per task must cover a failure or edge case.

---

## Quick Workflow Summary

```
PHASE 0: SCOPE CHALLENGE (INTERACTIVE)
├── Quick CodeMap scan for existing overlap
├── Estimate complexity
├── AskUserQuestion: present findings + mode selection
└── Gate: User confirmed scope + mode

PHASE 1: EXPLORE
├── CodeMap search for feature-related code
├── Read configs and directory structure
├── Build reuse audit table
└── Gate: Concrete file paths + reuse audit

PHASE 2: DECOMPOSE
├── Break into atomic TASK-NNN entries
├── 2-3 acceptance criteria per task (≥1 failure case)
├── Identify failure modes per task
├── Mode-aware pruning (REDUCTION/EXPANSION)
└── Gate: Atomicity checklist + failure modes

PHASE 3: MAP DEPENDENCIES
├── Check: file overlap, data flow, API contract, state
├── Minimize constraints for max parallelism
└── Gate: Valid DAG, no cycles

PHASE 4: PRIORITIZE
├── Assign P0-P3
├── Form parallel groups
└── Gate: Priorities + groups

PHASE 5: GENERATE
├── Markdown with all sections (scope, architecture, reuse, tasks, failures, tests, deps)
├── JSON companion file
├── Summary table
└── Gate: Both files saved, all sections present
```

---

## Resources

### references/

- **knowledge.md** — CodeMap tools reference, plan format parsing rules, DAG scheduling behavior, TaskDefinition interface
- **examples.md** — 4 complete examples: simple CRUD, complex multi-layer webhook system, cross-package plugin, bug fix decomposition

---

## Integration with Other Skills

The `plan-to-task-list-with-dag` skill integrates with:

- **`plan-founder-review`** — Review the generated plan before execution (quality gate)
- **`run-parallel-agents-feature-build`** — Execute the generated plan with parallel agents
- **`start`** — Use `start` first to identify if this skill is needed

**Workflow:** `start` → `plan-to-task-list-with-dag` → `plan-founder-review` → `run-parallel-agents-feature-build`

---

## Completion Announcement

When plan generation is complete, announce:

```
Plan generated.

**Mode:** EXPANSION | HOLD | REDUCTION
**Tasks:** X total (Y parallel groups)
**Files:** plans/<plan-name>.md + plans/<plan-name>.json

**Execution Summary:**
- Layer 0: TASK-001, TASK-004 (P0, no deps)
- Layer 1: TASK-002, TASK-003 (P1)
- Layer 2: TASK-005, TASK-006 (P2)

Ready for execution via `run-parallel-agents-feature-build`.
```