planner-refine
Targeted repair of validate_plan findings. Loads validation.json and repairs each
finding type: re-elaborates failed WPs, resolves duplicate deliverable ownership, and
fixes dependency reference errors. Sizing violations are escalated as CRITICAL. Writes
corrected artifacts back to the output directory so validate_plan can re-run.
The recipe runs this skill with retries: 2 — up to 3 total attempts (1 initial + 2
retries) before escalation.
When to Use
- Invoked by the planner recipe when
validate_planreturnsverdict: fail - One invocation per retry cycle
Arguments
- $1 — Absolute path to
validation.json - $2 — Absolute path to the run-scoped planner directory (e.g.,
{{AUTOSKILLIT_TEMP}}/planner/run-YYYYMMDD-HHMMSS)
Critical Constraints
NEVER:
- Attempt to auto-fix missing assignments or missing WPs — these require human review
- Remove a deliverable without reassigning it to another WP
- Introduce new WP IDs — the skill never creates WPs; it repairs or escalates existing ones
ALWAYS:
- Load
validation.jsonbefore reading any artifact - Fix all addressable finding types in a single pass
- Update
wp_manifest.jsonandwp_index.jsonwhenever WP structure changes - Escalate sizing violations, missing structural elements, malformed WP IDs, and DAG cycles as CRITICAL (write to stdout; do not count toward issues_fixed)
- Emit both
refinement_completeandissues_fixedoutput tokens
Workflow
Step 1: Load validation.json
Read $1. Extract the findings array (contains only error-severity findings as structured
dicts). Extract the message field from each finding for classification. Group by type:
- failed_wps: Findings matching
WP .* has status 'failed' - sizing_violations: Findings matching
WP .* has \d+ deliverables - duplicate_deliverables: Findings matching
Deliverable '.*' claimed by multiple WPs - dep_references: Findings matching
WP .* depends on unknown WP - missing: Findings matching
Phase .* has no assignmentsorAssignment .* has no work packages - malformed_id: Findings matching
WP .* has malformed id - dag_cycle: Findings matching
Cycle detected among WPs - files_touched_overlap (informational): Findings matching
File '.*' touched by multiple WPs— these appear in thewarningsarray, notfindings. No action needed; skip if encountered infindings.
Step 2: Load required artifacts
- Always load:
{$2}/work_packages/wp_manifest.json,{$2}/work_packages/wp_index.json - Load only the
{id}_result.jsonfiles for WPs mentioned in the findings
Step 3: Fix each finding type
Failed WPs — re-elaborate:
- For each failed WP ID, read its entry from
wp_manifest.json(providesname,scope,estimated_files) - Spawn a sub-agent with
model: "sonnet"per failed WP. Provide: WP name, scope, estimated_files, and the relevant portion ofwp_index.jsonfor context - Sub-agent writes a corrected
{$2}/work_packages/{id}_result.json - Sub-agent appends corrected compact entry to
wp_index.json - Update the WP status in
wp_manifest.jsonfromfailedtodone
Sizing violations — escalate:
- Findings matching
WP .* has \d+ deliverablesindicate WPs outside the 1–5 deliverable sizing bound. Cannot be auto-corrected — the implementation recipe handles re-splitting downstream.
CRITICAL: Cannot auto-fix sizing violation:
- {finding text}
Manual review of WP deliverable allocation required.
Write this to stdout. Do NOT attempt WP splitting or merging.
Duplicate deliverables — resolve ownership:
- For each duplicated file path, assign ownership to the WP whose scope most directly implements that file (strongest semantic claim)
- Remove the duplicate from the lower-priority WP's
deliverables(keep infiles_touched) - Post-deduplication orphan check: After resolving all duplicate deliverables, scan every
modified WP. If any WP now has
deliverables: [], that WP is an orphan. For each orphan:- Identify the WP(s) that received this orphan's former deliverables (the "owner WPs")
- Promote the orphan's
files_touchedentries as deliverables to the most relevant owner WP (the one with the most scope overlap), selecting at mostDELIVERABLE_BOUNDS[1] - len(owner.deliverables)entries. Any remaining entries stay infiles_touchedonly. - Merge the orphan's
technical_stepsandacceptance_criteriainto the owner WP - Remove the orphan WP from the plan and update all
depends_onreferences - Update
wp_manifest.jsonandwp_index.jsonaccordingly This is a deduplication side-effect resolved in the same step, not a sizing violation. Deliverable count bounds are defined inschema.py::DELIVERABLE_BOUNDS.
- Write updated
_result.jsonfor the affected WPs
Dependency reference errors — fix broken dep IDs:
- For each
WP X depends on unknown WP Yfinding:- Search
wp_index.jsonfor a WP with a similar name or scope to the missingY(it may have been renamed or split) - If a valid replacement is found, update
depends_onin{$2}/work_packages/{X}_result.json - If no valid replacement exists, remove the broken reference from
depends_on
- Search
- If
dep_graph.jsonexists, update it to reflect corrected dependency IDs
Missing assignments/WPs — escalate:
CRITICAL: Cannot auto-fix missing structural elements:
- {finding text}
Manual intervention required before validate_plan can pass.
Write this to stdout. Do NOT attempt structural creation.
Malformed WP IDs — escalate:
- Findings matching
WP .* has malformed id (expected PX-AY-WPZ)indicate a corrupted_result.jsonorwp_manifest.json. Cannot be auto-corrected without understanding the intended ID.
CRITICAL: Cannot auto-fix malformed WP ID:
- {finding text}
Manual inspection of wp_manifest.json required.
Write this to stdout. Do NOT attempt ID renaming.
DAG cycles — escalate:
- Findings matching
Cycle detected among WPs: ...indicate a circular dependency in the WP graph. Resolving cycles requires semantic understanding of the plan structure.
CRITICAL: Cannot auto-fix DAG cycle:
- {finding text}
Manual restructuring of depends_on relationships required.
Write this to stdout. Do NOT attempt cycle-breaking.
Step 4: Write corrected artifacts
Write all modified files back atomically (read current → apply change → write). Modified
files may include: _result.json files, wp_manifest.json, wp_index.json,
dep_graph.json.
Note: Combined documents (
combined_*.json,refined_*.json) are intermediate orchestration artifacts and are NOT updated by this skill. Downstream consumers (validate_plan,compile_plan) read from individual*_result.jsonfiles directly, so stale combined documents do not affect pipeline correctness.
Step 5: Emit output tokens
refinement_complete = true
issues_fixed = <N>
N = count of findings addressed from the findings array (failed_wps +
duplicate_deliverables + dep_references). Sizing-violation, missing-element, malformed-ID,
and DAG-cycle findings are excluded from the count (they are escalated as critical, not
fixed). Files-touched overlap findings are in the warnings array and are not actionable.