# Apply Pipeline

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

- Skill: `antiamerican-postponer432/apply-pipeline` (Agent Skill)
- Install (CLI): `npx skillmds@latest add antiamerican-postponer432/apply-pipeline`
- Raw SKILL.md: https://api.skillmd.com/api/skills/antiamerican-postponer432/apply-pipeline/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: antiamerican-postponer432 (https://skillmd.com/u/antiamerican-postponer432)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/antiamerican-postponer432/apply-pipeline

---


# $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` (sub-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 .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.