# Planner Reconcile Deps

> Post-Pass-3 global dependency DAG construction — detects implicit dependencies individual WP sessions could not see

- Skill: `talont-org/planner-reconcile-deps` (Agent Skill)
- Install (CLI): `npx skillmds@latest add talont-org/planner-reconcile-deps`
- Raw SKILL.md: https://api.skillmd.com/api/skills/talont-org/planner-reconcile-deps/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: TalonT-Org (https://skillmd.com/u/talont-org)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/talont-org/planner-reconcile-deps

---


# planner-reconcile-deps

Post-Pass-3 global dependency analysis. Reads the full `wp_index.json` (compact, ~12k
tokens for 60 WPs) and produces a corrected global dependency DAG. Detects implicit
dependencies that individual WP sessions could not see — forward references, transitive
chains, and API consumption patterns missed during per-WP elaboration.

Runs as a single LLM session for holistic cross-WP reasoning that per-WP sessions cannot
perform. The compact index fits entirely in context, enabling global analysis without
spawning parallel sessions.

## When to Use

- Invoked by the planner recipe immediately after Pass 3 completes
- One invocation per plan — processes the complete WP set

## Arguments

- **$1** — Absolute path to the run-scoped planner directory (e.g., `{{AUTOSKILLIT_TEMP}}/planner/run-YYYYMMDD-HHMMSS`)

## Critical Constraints

**NEVER:**
- Load full WP result files — only `wp_index.json` (the compact array)
- Spawn additional sessions — this skill must run as a single session for holistic reasoning
- Write output outside `{$1}/`
- Add transitive deps without a concrete API or file relationship as evidence

**ALWAYS:**
- Read `wp_index.json` in full before analyzing
- Populate `added_backward_deps` only when an `apis_consumed`/`apis_defined` or `files_touched` match justifies the dependency
- Emit `dep_graph_path` as the output token

## Workflow

### Step 1: Load wp_index.json

Read `{$1}/work_packages/wp_index.json`. This JSON array contains compact entries for
all WPs (~200 bytes each).

Each entry has: `id`, `name`, `summary`, `phase`, `assignment`, `files_touched`,
`apis_defined`, `apis_consumed`, `depends_on`, `deliverables`, `result_path`.

### Step 2: Analyze dependency relationships

Scan the full WP array holistically for:

1. **Implicit backward dependencies** — A WP has an `apis_consumed` entry that matches
   another WP's `apis_defined`, but the consuming WP does not list the defining WP in
   `depends_on`. These are missing backward deps that go into `added_backward_deps`.

2. **File-level implicit deps** — A WP's `files_touched` overlaps with a prior WP's
   `deliverables`, but no `depends_on` relationship exists. The later WP implicitly
   depends on the earlier.

3. **Forward dependency map** — For each WP, compute which other WPs depend on it
   (transpose of `depends_on`). This produces the `forward_deps` map.

4. **Reverse dependency consolidation** — Collect the existing `depends_on` arrays into
   the `reverse_deps` map for downstream consumers (e.g., `compile_plan`).

### Step 3: Build dep_graph.json

```json
{
  "forward_deps": {
    "P1-A1-WP1": ["P1-A2-WP1", "P2-A1-WP1"]
  },
  "reverse_deps": {
    "P1-A2-WP1": ["P1-A1-WP1", "P1-A1-WP2"]
  },
  "added_backward_deps": {
    "P2-A3-WP1": ["P1-A2-WP2"]
  }
}
```

- `forward_deps`: For each WP, list all WPs that depend on it (forward in execution order)
- `reverse_deps`: For each WP, list the WPs it currently depends on (mirrors `depends_on` arrays)
- `added_backward_deps`: New deps not declared in original `depends_on` — only when a concrete API/file match justifies the relationship

If no implicit deps are detected, write `added_backward_deps: {}`.

### Step 4: Write dep_graph.json

Write to `{$1}/dep_graph.json`.

### Step 5: Emit output tokens

```
dep_graph_path = <absolute path to dep_graph.json>
```