Before I write anything, let me classify this against the Iron Law and "Match the Form to the Failure."

## Classification

This is a **discipline failure**: agents know the integration suite exists, and skip it under pressure ("change is small", "lint passed", "diff looks clean"). They know better and rationalize anyway. That points to the prohibition + rationalization-table + red-flags form — NOT soft guidance, and NOT a positive recipe (the output shape isn't wrong; the step is being skipped).

But note: **I have not earned the right to write this guidance yet.** The Iron Law applies to edits to existing skills too: NO SKILL WITHOUT A FAILING TEST FIRST. I'm giving you the deliverable you asked for, but flagging that step (2) must happen *before* step (1) is deployed — and the baseline could change the wording.

I'll also note the cheaper alternative honestly: **if commit-without-integration-tests is mechanically detectable** (e.g., a pre-commit/pre-push hook that runs the suite, or CI that blocks the merge), that's the right fix. Documentation is for judgment calls; a hard gate beats a paragraph an agent can rationalize past. Add the guidance only for the cases a hook can't cover, or as a stopgap while the hook is built.

Assuming we still want the guidance, here is the draft to be validated by the plan below.

---

## (1) Exact guidance text

> ## Integration Suite Is Not Optional Before Commit
>
> The integration suite is the gate for commit, not lint. Lint and unit tests passing tell you nothing about integration. **You MUST run the full integration suite and see it pass before you commit.** No green integration run, no commit.
>
> **Violating the letter of this rule is violating its spirit.** "I integration-tested the spirit of the change" is not a passing run.
>
> This suite exists *because* small-looking changes have broken integration before. The size of the diff is not evidence about integration risk — it is the exact signal that has misled us into shipping breakage.
>
> ### No exceptions
>
> - Not for one-line changes
> - Not when lint and unit tests are green
> - Not when the diff "looks clean" or "obviously can't affect integration"
> - Not when the suite is slow and you're confident
> - Not "I'll run it after I commit" / "CI will catch it"
> - Slow is not a reason to skip. Start the suite, wait for it.
>
> ### Rationalization table
>
> | Excuse | Reality |
> |--------|---------|
> | "The change is small" | Small changes have broken integration before — that's why the suite exists. Diff size predicts nothing. |
> | "Lint passed, that's enough" | Lint checks style, not integration. Different layer, different failures. |
> | "Unit tests pass" | Unit tests mock the integration boundary. The suite tests what they mock out. |
> | "The diff looks clean" | "Looks clean" is reading; the suite is checking. You can't see integration failures by looking. |
> | "Obviously can't affect integration" | Every past breakage was "obvious" it wouldn't. Run it. |
> | "Suite is too slow right now" | Slow ≠ skippable. Start it, do something else, come back to the result. |
> | "I'll run it after committing / CI covers it" | Committing broken integration is the failure. After-the-fact isn't before-the-fact. |
>
> ### Red flags — STOP, run the suite, then commit
>
> - About to commit and you haven't seen the integration suite go green this run
> - Reasoning from diff size, "looks clean", or "obviously fine"
> - Citing lint/unit success as a substitute for integration
> - Planning to commit now and verify later
>
> **All of these mean: run the full integration suite, see it pass, then commit.**

I'd also tighten the skill's `description` to include the violation symptom, e.g. add "...before committing any change, including small or low-risk ones" so the skill loads at the moment of temptation.

---

## (2) Verification plan (must run BEFORE deploying the text above)

**RED — baseline, no guidance.** I cannot write the final wording until I've watched agents fail. Construct pressure scenarios combining the exact pressures you reported plus stackers:
- Small diff + lint green + time pressure ("reviewer waiting")
- Sunk cost ("you already spent the afternoon on this tiny fix")
- Authority ("lead said lint-clean is fine for one-liners")
- Exhaustion ("end of a long session, last task")

Run each scenario 5+ times with the *current* implementation skill (no new guidance). Record verbatim rationalizations. **If the baseline doesn't skip the suite, there's nothing to fix** — stop and don't add the paragraph. If it skips, the actual excuses I capture replace/augment my drafted rationalization table; I don't get to guess them.

**Micro-test the wording.** Before full scenarios, cheap fresh-context samples: system prompt = realistic implementer context (full skill + the task), user message = a tempting small change. Variants: (a) no-guidance control, (b) my draft, (c) a soft-guidance arm ("prefer running the suite"). 5+ reps each. Read every transcript manually — look for the agent quoting the rule but still committing. Success = consistent "ran suite, saw green, then committed" with low variance across reps. The soft arm should visibly underperform; if it doesn't, my form classification was wrong.

**GREEN.** Re-run the full RED pressure scenarios with the draft inserted. Agents must run the suite under every pressure combination.

**REFACTOR.** Any new rationalization found in GREEN gets an explicit row/red-flag added; re-test until bulletproof.

**Deployment gate.** Commit only after GREEN holds under combined pressure. And before merging: confirm with you whether a pre-push/CI hard gate is feasible — if so, the hook is primary and this guidance is the judgment-call backstop.

Want me to start the RED baseline runs, or first scope whether a CI/pre-push gate can enforce this mechanically?