Before I write anything, let me flag the Iron Law: **no skill edit without a failing test first.** What follows is a *draft proposal*, not deployable guidance. The verification plan is the part that determines whether this text survives — and it must run before this goes into the skill.

Let me also classify the failure, because that dictates the form.

## 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 do it anyway. Per *Match the Form to the Failure*, the right form is **prohibition + rationalization table + red flags**, keyed to a hard gate — not soft guidance.

The three quoted excuses are gold: they're real baseline rationalizations. But I have only three, secondhand. The verification plan needs to surface the *full* set verbatim before I lock the table.

## (1) Draft guidance text

> ## Integration suite is a hard gate before commit
>
> **You MUST run the project's integration suite and see it pass before committing any change that touches code.** Not lint. Not unit tests alone. The integration suite.
>
> The integration suite exists *because* small, clean-looking changes have broken integration in the past. The size of the diff tells you nothing about integration risk. "Looks fine" is the exact condition under which this breaks.
>
> **Violating the letter of this rule is violating the spirit of it.** "I followed the spirit by being careful" is not running the suite.
>
> ### No exceptions
> - Don't skip because the change is small or "one line."
> - Don't skip because lint passed — lint and integration test different things.
> - Don't skip because unit tests passed — they don't exercise integration.
> - Don't skip because the diff "looks clean" — appearance is not a test result.
> - Don't commit "to save the work" and run the suite after — a commit is the gate, not a checkpoint.
> - Don't skip because the suite is slow — slow is the cost of the gate, not a reason to bypass it.
>
> ### Rationalization table
> | Excuse | Reality |
> |--------|---------|
> | "The change is small" | Small changes have broken integration before — that's why the suite exists. |
> | "Lint passed, that's enough" | Lint checks style/syntax, not integration behavior. Different layer. |
> | "Unit tests passed" | Unit tests isolate components; integration is exactly what they don't cover. |
> | "The diff looks clean" | Visual review is not test execution. You cannot eyeball integration. |
> | "It's too slow to run every time" | The suite's runtime is known and accepted; bypassing it is not your call to make. |
> | "I'll run it after I commit" | The commit IS the gate. After-the-fact runs don't ungate a broken commit. |
>
> ### Red flags — STOP before committing
> - About to commit and you have NOT seen the integration suite pass on this change
> - Thinking "this one's too trivial to bother"
> - Justifying with lint or unit results instead of integration results
> - "I'm confident it's fine"
>
> **All of these mean: run the integration suite to completion, see it pass, then commit.**

I'd add violation symptoms to the skill's `description` (e.g. "...before committing any code change") so it loads when an agent is at the commit step.

## (2) Verification plan (runs BEFORE deploying)

**RED — establish the baseline (the part I cannot skip):**
1. Build 3+ pressure scenarios combining the real pressures: time crunch + sunk cost ("you've been at this for hours") + the actual quoted excuses + authority ("reviewer said small changes are fine"). Scenario task: a one-line-looking change, lint green, unit green, slow integration suite available.
2. Run each scenario with a fresh subagent **without** the guidance. Record verbatim what they do and every rationalization they produce. This is mandatory — if I don't watch it fail, I don't know what to write. The three known excuses become my seed; I expect new ones (e.g. "CI will catch it", "I'll let the suite run async").

**Micro-test the wording (cheap, before full scenarios):**
3. System prompt = the full edited skill in realistic context; user message = a commit-step task that tempts skipping. 5+ reps per variant, plus a **no-guidance control**. If the control doesn't skip, there's nothing to fix.
4. Read every flagged response manually — template echoes and quoted counter-examples fake both passes and failures. Check variance: 5 reps should converge on "ran the suite, saw it pass, committed."

**GREEN:**
5. Re-run the full pressure scenarios with the guidance present. Success = agent runs the suite to completion and refuses to commit until it passes, under maximum combined pressure.

**REFACTOR:**
6. Any new rationalization from GREEN runs → add an explicit row/red flag → re-test until bulletproof. No nuance clauses ("unless truly trivial") — those reopen the negotiation.

**Note on form:** this is a discipline skill, so prohibitions are correct here. But if testing reveals the agent *runs* the suite yet commits on a flaky/partial result (a wrong-shape problem, not a skip), I'd switch that piece to a positive contract ("a commit requires a full green run") rather than more prohibitions.

I will not add this to the skill until the RED baseline is recorded and GREEN passes.