code-refine

name	code-refine
description	Use only when autopilot-code dispatches plan revision after user notes, plan-check feedback, or verification failure. Not for top-level user requests or primary capability routing.
argument-hint	<plan name or path> [--intensity direct|quick|standard|strong|thorough|adversarial]
metadata	{"group":"sub","fam":"sub","invocation_class":"parent-invoked","modes":[],"blurb":"Revise an existing plan using user notes, plan-check feedback, and verification-failure notes.","use_when":"Use only when autopilot-code dispatches plan revision after user notes, plan-check feedback, or verification failure.","not_for":"Not for top-level user requests or primary capability routing."}

code-refine

Plan resolution: Treat arguments-and-decisions.md#plan-resolution as the single authority for resolving $ARGUMENTS. Recognize both canonical plan.md and any existing companion such as legacy plan_ko.md; swap between known companion paths only when both files actually belong to the same plan.

Language rule: Follow the audience and artifact language contract in arguments-and-decisions.md#language-rule. Preserve the canonical plan's selected language and synchronize only companions that already exist or are explicitly required.

Delegate Refinement

Re-enter the plan/plan-author unit boundary with this task:

Refine mode. Update an existing implementation plan from user memos, plan-check feedback, or verification-failure notes.

Supplied plan: {$ARGUMENTS}
Canonical plan: {resolved plan.md path}
Existing companion plans: {resolved paths, or none}

Read the supplied and canonical plan files and identify user memos per your refine-mode memo forms; additionally treat any HTML comment as a user memo. Do not treat original plan prose as a memo. Then follow your refine-mode procedure and return format.

Memo forms, in-place update, companion synchronization, and the single-line return contract are owned by the plan/plan-author unit persona; do not restate them in the prompt.

Refine Assurance

Derive verification rigor from the plan's selected --intensity context under CONVENTIONS §1.1. This capability is an optional correction of a durable plan; it is not an automatic stage in direct or quick.

Rigor	Review after refinement	Correction budget
quick	Direct invocation only: one fast sanity review or self-check	Record residual concerns; no repeated loop
light	One focused fast review when changed steps could affect execution	One bounded correction for blocking issues
standard	One lightweight qa/plan-review unit pass (the plan-check boundary) over changed steps	At most one correction
thorough	Multi-axis review only when selected by intensity=thorough	Up to two synthesized corrections
adversarial	Thorough review plus explicit failure-mode, security, and adversarial critique when available	Explicit unavailable requests fail loudly; automatic escalation falls back to thorough and reports it

After the plan/plan-author unit returns, run only the review action selected by the caller's graph. Do not open a repeated QA loop merely because the rigor tier is high. Add unresolved concerns to the plan's risk or unresolved section after the selected budget and report them to the caller.

Task

Refine the plan at: $ARGUMENTS