Apply Pipeline

---
name: apply-pipeline
description: The write-side inverse of /check-pipeline and the pipeline-auditor — read a Pipeline/ doc (and/or an audit report) and EDIT the code accordingly: apply an optimization the pipeline describes, correct code the pipeline (backed by your authoritative notes) shows is wrong, or bring the code in line with the documented behavior. Use when the user wants the code changed based on the pipeline. High-stakes: bakes in live-editor editing, mirror sync, ground-truth protection, and control-gating. Proposes a diff and gets approval before any risky edit.
---

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

This closes the loop with the other pipeline tools:

| tool | direction | writes? |
|---|---|---|
| `/write-pipeline` | code → new doc | doc |
| `/check-pipeline` | code vs doc → drift report | doc (on approval) |
| `pipeline-auditor` (agent) | code via doc → bug/opt report | nothing (read-only) |
| **`/apply-pipeline`** | **doc/report → code edits** | **code** (with guards) |

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 .claude/skills/write-pipeline/dump_code.py "$SCRATCH" "<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 `CLAUDE.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 the `Write` tool — a blind `Write`
  won't reload into the open editor and you'll fight a stale buffer. If it's closed, `Edit`/`Write`
  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.