This is a discipline failure (agents know the suite exists, skip it under "small change" pressure), so the Iron Law applies: **no skill edit without a failing test first.** I'll show you the guidance I'd add, but flag clearly that it must not ship until baseline + verification confirm it works.

## Classification

Per "Match the Form to the Failure": agents know the rule and skip it under pressure ("change is small", "lint passed"). That's the **discipline-failure row** → prohibition + rationalization table + red flags is the right form. The rationalizations below are placeholders pulled from your description; the *real* ones must come from baseline runs before this is final.

## (1) Proposed guidance text (DRAFT — untested)

```markdown
## Integration Suite Before Commit (Non-Negotiable)

Run the full integration suite and see it pass before you commit. Not lint.
Not unit tests. The integration suite.

**Violating the letter of this rule is violating the spirit of it.**

The integration suite exists because small-looking changes have broken
integration before. "Small" is exactly the case it's there to catch — the
size of the diff is not evidence about integration impact.

### Red Flags — STOP and run the suite

- "The change is small / one-line / trivial"
- "Lint passed, that's enough"
- "The diff looks clean"
- "Unit tests cover this"
- "It's only a config/comment/rename change"
- "I'll run it after I commit / in CI"
- "I ran it last time and nothing relevant changed"

**All of these mean: run the integration suite now, before committing.**

### Rationalization Table

| Excuse | Reality |
|--------|---------|
| "Change is too small to break integration" | Small changes are why the suite exists. Size predicts nothing about integration impact. |
| "Lint passed" | Lint checks style, not behavior across components. Different layer. |
| "Diff looks clean" | Clean diffs break integration constantly. Reading code ≠ running it. |
| "CI will catch it" | CI catching it after commit means you shipped a known-untested change. Catch it before. |
| "I ran it recently" | The suite tells you about *this* change. Stale runs don't. |

If the suite is genuinely too slow to run per-commit, that's a tooling
problem to raise — not a license to skip. Skipping is never the fix.
```

Notes on form choices:
- Prohibition + table + red flags, because this is discipline, not output-shaping.
- No nuance/exemption clauses inside the rule ("unless trivial") — those reopen the negotiation. The slow-suite concern is handled as a separate escalation path, not an exemption.

## (2) Verification plan (do this BEFORE deploying)

**RED — baseline, no skill present:**
1. Write 3+ pressure scenarios combining the real pressures: time ("reviewer waiting"), sunk cost ("already spent an hour"), authority ("lead said small changes are fine"), plus the specific "lint passed / diff is clean / change is small" framings.
2. Run each scenario with a fresh subagent **without** the guidance. Record verbatim what they do and every rationalization they use. **If they don't skip the suite, there's nothing to fix — stop.**
3. Compare their actual rationalizations against my draft table. Replace my guessed excuses with their real wording.

**Micro-test the wording (cheap iteration before full scenarios):**
4. System prompt = the full implementation skill *with* the draft guidance; user message = a task that tempts skipping. Run 5+ reps, plus a no-guidance control.
5. Read every transcript manually (don't just keyword-count). Check: did they run the integration suite before committing? Did variance collapse to one shape, or five different interpretations?

**GREEN — with skill:**
6. Re-run the original pressure scenarios with the guidance present. Agents should comply under maximum combined pressure.

**REFACTOR:**
7. Any new rationalization that appears → add a row + red flag, re-test until bulletproof.

**Then deploy:** only after GREEN holds. Commit and push.

If you want, point me at the baseline scenario transcripts (or let me generate and run them) and I'll tighten the table to the rationalizations agents *actually* produce rather than the ones we're guessing at.