Apply Pipeline

$apply-pipeline — turn a pipeline (or audit) into code edits

This closes the loop with the other pipeline tools:

Use it when the user wants the code changed on the basis of the pipeline: implement an optimization the pipeline names, correct code the pipeline (backed by your authoritative notes) shows is wrong, or reconcile code to documented behavior.

Source-of-truth rule (READ FIRST — it decides whether you should edit code at all)

In a research project the code and the committed data are usually ground truth; the pipeline is a map of intent. So when code and pipeline disagree, the usual fix is to change the doc ($check-pipeline), NOT the code. Only edit code when one of these holds:

1. The user explicitly asks for the code change ("apply this optimization", "make the code do X").
2. The pipeline — and the authoritative notes it cites (workbook.tex / the paper) — together show the code is genuinely wrong (a real bug), and the user has confirmed they want it fixed. Otherwise, STOP and recommend $check-pipeline instead. Never "fix" code to match a doc that is itself the thing that's stale.

Method

1. Read the inputs. The pipeline doc, the notes section(s) it cites (grep workbook.tex for the labels — the authority for why), and, if you're acting on an audit, that report. Dump the code if it's a notebook: python3 .agents/skills/write-pipeline/dump_code.py "/tmp/pipeline-dumps" "<code>".

2. Pin the exact change. State precisely what will change, in which cells/functions, and why (cite the pipeline line + notes label). Confirm the change preserves the documented behavior (for an optimization: identical output) or corrects it (for a bug: cite the correct form).

3. Classify risk and gate.

• LOW (apply, then validate): comments/dead-code, a pure refactor or optimization that provably gives identical output (e.g. replacing a Do+append loop with a vectorized build, hoisting an invariant, memoizing a pure function).
• HIGH (PREVIEW a diff + get explicit approval FIRST): anything touching the core math, a normalization/truncation convention (it changes what cached data means), or definitions other code depends on. Never overwrite committed results / cached numeric tables / solved outputs — those are the user's ground truth (see AGENTS.md "AI-generated outputs"); regenerating data needs an explicit instruction.

4. Apply with the right mechanism.

• If the target notebook is open in a live-kernel editor (e.g. a .wb in VS Code via the Wolfbook MCP): edit it through that editor's tools, NOT by overwriting the file on disk — a blind disk write won't reload into the open editor and you'll fight a stale buffer. If it's closed, editing the file directly is fine.
• After any edit to one half of a mirrored pair (e.g. .wb ↔ .nb), propagate to the other and verify parsed-code equality. Keeping mirrors in sync is non-negotiable.
• Respect the code's line/format constraints (e.g. keep each statement on one physical line if the runner splits on newlines).

5. Validate — do not trust the edit blind.

• Re-run the edited cell(s)/function in the live kernel or interpreter, and read + act on any error banner (an undefined symbol, a shape/structure mismatch = STOP and fix).
• Gate on a control: after a change that could affect a result, re-run a known-good control case and confirm it still passes. If a control breaks, REVERT (a kernel checkpoint/restore, or a saved intermediate, makes this cheap) — the edit was wrong.
• For an "identical-output" optimization, assert equality on a sample before/after (old - new === 0 on a few entries) before declaring done.

6. Reconcile the doc + report. If the edit changed cell numbers, symbol names, or documented structure, update the pipeline .md (or run $check-pipeline --fix). Report: what changed, why, the validation result (control passed / sample identical), and anything deferred.

What this skill will NOT do without an explicit, specific instruction

• Regenerate or overwrite any committed result / cached numeric table / solved output.
• Change a mathematical result, or a convention that redefines what cached data means.
• Edit the authoritative notes (workbook.tex / Overleaf — those have their own skills).
• Push or commit (commit/push only when the user asks). For any of those, surface the proposal and stop.