| 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:
- The user explicitly asks for the code change ("apply this optimization", "make the code do X").
- 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.
