This is a discipline failure — agents know the suite exists and skip it under pressure ("change is small"). Per the Iron Law, I cannot deploy this guidance without watching it fail first. But I can write the candidate guidance and lay out the verification plan that gates deployment.

## Classifying the failure

Using **Match the Form to the Failure**: agents know the rule and violate it under pressure. That's a discipline failure → prohibition + rationalization table + red flags. The baseline rationalizations are already supplied verbatim ("the change is small", "lint passed, that's enough", "the diff looks clean"), which is exactly the RED-phase material I'd otherwise have to generate. I'll still need to run the baseline to confirm these are the *actual* triggers and catch new ones — but they seed the first draft.

---

## (1) Exact guidance text to add to the implementation skill

```markdown
## Run the Integration Suite Before Committing

**Run the full integration suite and see it pass before every commit. No exceptions.**

The integration suite exists because small-looking changes have broken integration
before. The size of the diff tells you nothing about integration risk — that is
precisely the failure mode this rule prevents.

**Violating the letter of this rule is violating the spirit of it.** "I followed the
intent" while skipping the suite is skipping the suite.

### No exceptions

- Not when the change is one line
- Not when lint/typecheck/unit tests passed
- Not when the diff "looks clean" on review
- Not when you're confident
- Not when you're out of time (out of time = not done, not "commit anyway")
- Not when you "already ran it earlier" before your last edit

If you commit without a passing integration run, the change is not done.

### Rationalization table

| Excuse | Reality |
|--------|---------|
| "The change is small" | Diff size does not predict integration breakage. The suite exists because small changes broke integration before. |
| "Lint passed, that's enough" | Lint checks style, not integration. Different layer, different failures. |
| "Unit tests passed" | Unit tests mock the boundaries integration tests actually exercise. |
| "The diff looks clean" | Clean-looking diffs broke integration before — that's the whole reason this rule exists. |
| "I ran it earlier" | You edited since then. Stale runs prove nothing about current code. |
| "It's slow and I'm confident" | Slow < debugging a broken main branch. Confidence is not a passing run. |
| "I'll run it after committing" | A commit that breaks integration is already on the branch. After is too late. |

### Red flags — STOP and run the suite

- About to commit and the integration suite has not run on the current code
- Telling yourself the change is too small to break anything
- Substituting lint/unit/typecheck for the integration suite
- Reusing a result from before your latest edit
- "Just this once because [reason]"

**All of these mean: run the full integration suite now, see it pass, then commit.**
```

---

## (2) Verification plan before deploying

I will **not deploy until this passes the gate below.** Per the Iron Law, the draft above is a hypothesis, not a finished skill.

**RED — establish baseline (required before trusting the draft):**
1. Write 3+ pressure scenarios combining real incentives an implementer feels: time pressure ("ship before standup"), sunk cost ("you've been on this 3 hours"), authority ("lead said it's trivial"), and the suite's slowness (15+ min). Each scenario presents a genuinely small diff with lint/unit already green.
2. Run each scenario with subagents **without** the guidance. Record verbatim what they say and whether they commit. Confirm the supplied excuses reproduce and capture any *new* rationalizations the draft doesn't yet cover.
3. If the control doesn't skip the suite, there's nothing to fix — stop and reconsider whether guidance is needed.

**Micro-test the wording (cheap, before full scenarios):**
4. System prompt = the full implementation skill *with* the candidate guidance inserted (realistic context, not the guidance in isolation). User message = a task that tempts skipping. Run 5+ reps per variant, always against a no-guidance control.
5. Read every flagged "complied/violated" match manually — quoted counter-examples and template echoes masquerade as hits. Check variance: if 5 reps converge on "ran the suite," the wording is binding; 5 different interpretations means tighten the form, not add words.

**GREEN — verify compliance:**
6. Re-run the original RED scenarios *with* the guidance. Success = agent runs the full suite and sees it pass under every combined pressure.

**REFACTOR — close loopholes:**
7. Any new rationalization that appears (e.g., "I'll run just the affected subset") goes into the table as its own row and into red flags. Re-test until bulletproof.

**Only after GREEN holds under maximum combined pressure do I commit and deploy.**

One note for you: if "ran the integration suite" is mechanically detectable (e.g., CI status, a required check), prefer enforcing it with a pre-commit/CI gate over documentation — skills are for judgment calls, and mechanical constraints should be automated. This guidance is the right tool only where the run can't be hard-gated.