This is a request to add discipline-enforcing guidance to an existing skill. The Iron Law applies to edits just as much as new skills: **no skill change without a failing test first.** So I'll give you the guidance text, but I want to be explicit that the guidance below is a *draft to be tested*, not deployment-ready.

Let me classify the failure first, because that determines the form.

## Failure classification

The agents *know* the suite exists and *choose* to skip it under pressure, citing rationalizations ("change is small", "lint passed", "diff looks clean"). That is a **discipline failure** — knows the rule, violates it under a competing incentive (speed). Per *Match the Form to the Failure*, the right form is **prohibition + rationalization table + red flags**, not soft guidance. The rationalizations you've already supplied are gold — they're the verbatim baseline output I'd otherwise have to generate. They go straight into the table.

## (1) Exact guidance text

```markdown
## Integration Tests Are Not Optional Before Commit

**Skipping the integration suite is skipping the test. There is no "small enough" change.**

The integration suite exists *because* small-looking changes have broken
integration before. The size of your diff is not evidence about integration
behavior — that's exactly the correlation the suite was built to catch and
that your intuition has already gotten wrong.

**Before every commit, run the full integration suite and see it pass.**
Not lint. Not unit tests alone. The integration suite. Green output in your
scrollback, this run, this change.

### Red Flags — STOP, You Are About to Skip the Suite

- "The change is small / one line / trivial"
- "Lint passed, that's enough"
- "The diff looks clean"
- "Unit tests cover this"
- "I'll run integration in CI / later / if something breaks"
- "I already ran it on the last change"
- "This file isn't even in the integration path"

**Every one of these means: run the full integration suite now, before committing.**

### Rationalization Table

| Excuse | Reality |
|--------|---------|
| "The change is small" | Small changes are exactly what has broken integration before. Size predicts nothing about integration impact. |
| "Lint passed, that's enough" | Lint checks style, not behavior. It cannot tell you whether components still work together. |
| "The diff looks clean" | "Looks clean" is a guess. The suite is the measurement. You don't get to substitute the guess for the measurement. |
| "Unit tests cover this" | Unit tests prove components work in isolation. Integration breaks live *between* components, where unit tests can't see. |
| "I'll let CI catch it" | CI catching it = you committed a break and shifted the cost downstream. Catch it before the commit. |
| "I ran it last time" | A previous green run says nothing about the current change. Re-run for this diff. |
| "This file isn't in the integration path" | If you could reliably predict the integration path, the suite would be unnecessary. You can't, so run it. |

**Violating the letter of this rule is violating its spirit.** "I followed the
intent by being careful" is not running the suite. Run the suite.
```

A note on placement: this is structural guidance for a step the agent already performs (committing), so it should sit adjacent to the commit step in the skill, not in a distant "tips" section — reminders far from the template they constrain get skipped.

## (2) Verification plan before deploying

I will not deploy this until it passes RED-GREEN-REFACTOR. The text above is **untested production code**.

**RED — establish the baseline (required even though you handed me rationalizations):**
- Write 3+ pressure scenarios combining incentives: time pressure ("we're shipping in 10 minutes"), sunk cost ("you've already run unit tests twice"), authority ("the lead said lint is the gate"), and triviality ("it's a one-line copy change").
- Run each scenario with a subagent **without** the new guidance. Record verbatim what they do and what they say. Confirm they actually skip the suite — if a no-guidance control already runs the suite, there's nothing to fix and I stop.

**Micro-test the wording (cheap iteration before full scenarios):**
- System prompt = the full implementation skill *with* the draft guidance inline (realistic context, not the snippet in isolation). User message = a task that tempts skipping.
- 5+ reps per variant, plus the no-guidance control.
- Read every transcript by hand — watch for the agent quoting the rationalization table back at me while still skipping, which automated matching would miscount as a hit.
- Variance check: if 5 reps produce 5 different behaviors, the wording isn't binding yet — tighten before adding words.

**GREEN — re-run the full pressure scenarios with the guidance.** Success = agent runs the integration suite before committing under maximum combined pressure.

**REFACTOR — capture any new rationalization the agents invent** (they will find loopholes — e.g. "I ran a subset of integration tests"), add an explicit counter row, and re-test until bulletproof. If a new loophole like "subset is fine" appears, I'd add "the *full* suite, not a subset you chose" rather than a vague nuance clause.

Only after GREEN holds under pressure do I commit and push.

**One caution:** if it turns out this is mechanically enforceable — e.g. a pre-commit/CI gate that blocks commits without a passing integration run — that's a stronger fix than documentation. Per the skill's "Don't create for: mechanical constraints" guidance, automate it rather than relying on judgment. I'd raise that option with you before settling on the prose-only approach.