fix

name	fix
description	Diagnose, plan, approve, repair, and prove a defect fix. Use when the user explicitly invokes the fix pipeline.

Fix pipeline

Use this pipeline when something is broken and the cause is not yet established. The diagnosis bounds the plan: do not plan past what the reproduction demonstrates, and do not widen the repair beyond the diagnosed cause.

Use the task supplied alongside this explicitly invoked skill. Record the actual runtime, codex or copilot, as harness in the run ledger.

1. Intake

Clarify the requested outcome from available context. Inspect the repository before asking questions that the files can answer. Create the run folder and write task.md containing the outcome, constraints, assumptions, and acceptance checks. Reserve an empty evidence/ folder.

2. Diagnose

Reproduce the reported behavior first and capture the failing command and its output in the run folder as diagnosis.md, then isolate the smallest cause that explains it. State the root cause, the affected surface, and nearby risks. If the failure cannot be reproduced, stop and report that instead of guessing at a fix.

3. Plan

Write plan.md in the run folder. Name the files or components to change, the intended behavior, the verification commands, and material risks. Keep the plan executable by another capable agent.

Gate: plan-approval

STOP after completing this stage. Do not execute until the user explicitly approves the written plan. Request the verdict by writing approvals/plan-approval.md.request in the run folder describing what needs approval, then stop. The verdict is recorded from outside the session: base approve <run-slug> plan-approval (or --deny) writes approvals/plan-approval.md — a standing directive counts only when recorded that way, with --note citing it. Never create the verdict artifact yourself. If the recorded verdict is denied, skip to record with outcome aborted.

4. Execute

Implement the approved plan without widening scope. Run the planned checks and capture a concise result.md with changed paths, verification results, and any remaining limitations. Put durable proof files under evidence/ when useful.

5. Verify

Run the acceptance checks named in task.md and the approved plan. Capture the commands and their real output as files under evidence/; reference them from result.md with a pass or fail verdict per check. A failing check means the run is not completed — fix it or record the honest outcome. Never substitute a claim for a captured result.

6. Record

Always run this stage, including after rejection, failure, or abort. Append exactly one compact JSON object line to .base/history.jsonl with slug, date, pipeline, harness, outcome, and paths. Use completed, aborted, or failed for outcome; never rewrite previous lines.