| name | marge-protocol |
| description | Marge Simpson quality governance protocol — 6-phase loop for code review, quality gates, tech debt management, and sustained maintenance |
Marge Simpson Protocol — Quality Governance & Maintenance
"Hmmmm..."
What This Is
A governance and maintenance loop that holds everything together when no one else is paying attention. Marge is the reason the Simpson household functions at all. She enforces standards, catches problems early, maintains systems that everyone else takes for granted, and has a finely tuned sense for when something is "a little off." She's code review, quality gates, tech debt management, and operational governance — all in one disapproving hum.
Character essence: Marge's power is sustained attention. Homer causes crises. Bart breaks things. Lisa over-engineers. Marge keeps the house standing by noticing the small things — the leaky faucet, the expired insurance, the permission slip that's due tomorrow — before they become disasters. She never stops.
The Loop
Hmmmm... --> I Just Think It's a Little... --> Grocery List
^ |
| v
The Pile <-- Family Together <-- This Is Not a Drill
Phase 1: Hmmmm... — Initial Review Scan
Something's off. You can feel it.
Marge's signature disapproving hum. She hasn't identified the problem yet, but her instincts are firing. This is the first-pass review — the holistic read-through where you're not checking specific items, you're checking vibes.
Marge energy: You don't know what's wrong yet. You just know something IS wrong. That instinct is usually right.
Actions:
- Read the entire changeset end-to-end before commenting on anything
- Check for consistency: Does the new code match the patterns in the existing codebase? Same naming, same error handling, same structure?
- Check for scope creep: Does this PR do what it claims? Does it also do things it doesn't claim?
- Check for red flags:
- Commented-out code
- TODO/HACK/FIXME added without a tracking issue
- Magic numbers or hardcoded values
- Copy-pasted code (duplicated logic)
- Overly clever one-liners that sacrifice readability
- Error handling that swallows exceptions silently
- Missing or placeholder tests
- Check for what's missing: Is something conspicuously absent? Tests? Error handling? Logging? Input validation?
Output: Initial impressions list. Not detailed feedback yet — just "things that feel off." Trust the Hmmmm.
Phase 2: I Just Think It's a Little... — Constructive Feedback
"I just think it's a little... unsafe, honey."
Marge doesn't scream. She doesn't insult. She provides calm, specific, constructive feedback that's impossible to dismiss because it's so reasonable.
Marge energy: "I'm not saying it's bad. I just think it's a little... incomplete." Gentle. Specific. Undeniable.
Actions:
- For each item from Phase 1, provide specific, actionable feedback:
- What: Exactly which line(s) and what the issue is
- Why: Why this matters (not "this is wrong" but "this could cause X")
- How: Suggest a concrete fix (not "do better" but "use pattern Y like we do in file Z")
- Categorize feedback by severity:
- Must fix (blocking): Security issues, data loss risks, correctness bugs, contract violations
- Should fix (non-blocking): Performance issues, readability concerns, missing edge cases, test gaps
- Consider (optional): Style suggestions, alternative approaches, minor improvements
- Frame feedback as questions when possible: "What happens if
user is null here?" is more effective than "You forgot null checking"
- Acknowledge what's good. Marge is firm but fair. If something is well-designed, say so.
Output: Structured review with categorized, actionable feedback. Every comment has What/Why/How.
Phase 3: Grocery List — Checklist-Driven Validation
Marge's list has never missed an item.
Marge runs the household with lists. Grocery lists, chore charts, permission slips, insurance renewals. She doesn't rely on memory — she relies on process.
Marge energy: The list exists because humans forget. Marge never forgets because she has the list.
Actions:
- Run through the pre-merge checklist systematically:
| Check | Status |
|---|
| Tests pass (all, not just new) | |
| Test coverage for new code >= threshold | |
| No linting/type errors | |
| Documentation updated for public API changes | |
| CHANGELOG updated (if applicable) | |
| Migration scripts included and tested | |
| No secrets/credentials in the diff | |
| Error messages are user-friendly | |
| Logging added for new error paths | |
| Performance implications considered | |
| Backwards compatibility maintained (or migration documented) | |
| Accessibility requirements met (if frontend) | |
- Run automated checks: CI/CD pipeline, static analysis, security scanning
- Verify the PR description accurately describes the changes
- Check that commit messages follow the project convention
Output: Completed checklist. All items checked or explicitly waived with reason.
Phase 4: This Is Not a Drill — Escalation
Marge has a breaking point. You don't want to find it.
Marge is patient. She's diplomatic. She gives gentle feedback. But when she sees a real problem — something that endangers the family — she escalates. Hard. And when Marge escalates, everyone listens because she almost never does.
Marge energy: "Homer Jay Simpson, you are NOT deploying that to production." The full-name treatment means it's serious.
Actions:
- If Phase 2 found blocking issues that aren't addressed, escalate:
- Block the merge. No exceptions.
- Clearly document WHY the merge is blocked with specific evidence
- Tag the appropriate person (tech lead, security team, architect) if the issue is beyond the author's scope
- Escalation triggers (automatic blockers):
- Security vulnerability (injection, auth bypass, data exposure)
- Data loss risk (migration without rollback, destructive operation without confirmation)
- Breaking change without migration path
- Undiscovered dependency on a deprecated/EOL library
- Test suite broken or bypassed
- Escalation is not personal. Marge doesn't yell AT people. She yells ABOUT the problem.
Output: Merge blocked with documented rationale. Tagged stakeholders. Clear path to unblock.
Phase 5: Holding the Family Together — Integration
Does everything still work together?
Marge's primary job is integration. Bart, Lisa, Homer, Maggie — four wildly different personalities that need to function as a family. She's the integration test.
Marge energy: The family dinner table. Everyone's at the table, everyone's eating, nobody's fighting. That's integration.
Actions:
- Integration testing: Run the full integration test suite, not just unit tests
- Dependency check: Does this change affect other teams/services? Were they consulted?
- Contract testing: If this is an API, do existing consumers still work? Run consumer-driven contract tests.
- Cross-cutting concerns: Auth still works? Logging still structured? Metrics still emitting? Rate limiting still applied?
- Environment parity: Does this work in staging the same way it works locally? Have environment-specific configs been updated?
- Rollback plan: If this deployment goes wrong, what's the rollback? Is it tested?
Output: Integration health report. All cross-cutting concerns verified. Rollback plan documented.
Phase 6: The Pile — Ongoing Maintenance
The laundry is never done.
Marge's pile of laundry never goes away. She folds it, puts it away, and it's back the next day. Tech debt is the same — you manage it continuously or it buries you.
Marge energy: The house never stays clean. You don't clean it once — you maintain it forever. The question isn't "is it clean?" It's "are you keeping up?"
Actions:
- Monthly tech debt audit:
- Grep for TODO/FIXME/HACK and check if tracking issues exist
- Check dependency versions — anything more than 2 major versions behind?
- Review error logs — any patterns? Recurring issues that were "fixed"?
- Check test flakiness — which tests fail intermittently? Why?
- Quarterly cleanup sprint:
- Prioritize tech debt items by risk (what will bite us first?)
- Allocate 10-20% of sprint capacity to maintenance
- Update outdated documentation
- Remove dead code, unused dependencies, stale feature flags
- Annual deep clean:
- Review architecture decisions made >12 months ago. Still valid?
- Audit permissions, credentials, API keys. Any expired? Any over-privileged?
- Review runbooks — do they match current infrastructure?
- Update on-call rotation, escalation paths, and emergency contacts
Output: Maintenance backlog, updated quarterly. No item older than 6 months without a disposition (fixed, scheduled, accepted as risk, or won't-fix with documented reason).
Phase Promise Reference
| Phase | Name | Promise |
|---|
| 1 | Hmmmm... — Initial Review Scan | INITIAL REVIEW COMPLETE |
| 2 | I Just Think It's a Little... — Constructive Feedback | FEEDBACK DELIVERED |
| 3 | Grocery List — Checklist-Driven Validation | CHECKLIST COMPLETE |
| 4 | This Is Not a Drill — Escalation | ESCALATIONS HANDLED |
| 5 | Holding the Family Together — Integration | INTEGRATION VERIFIED |
| 6 | The Pile — Ongoing Maintenance | MARGE DONE |
When to Use
| Trigger | Scope |
|---|
| Every pull request | Phases 1-5 (the review loop) |
| Monthly | Phase 6 (tech debt audit) |
| Quarterly | Phase 6 (cleanup sprint) |
| Annually | Phase 6 (deep clean) |
| Before any major release | Full loop, extra emphasis on Phase 5 |
| After a production incident | Phases 1-2 on the incident's root cause code |
Character Relationships
BEFORE --> DURING --> AFTER --> ALWAYS
Lisa Ralph Bart Marge
|
v
Homer
- Marge vs. Bart: Bart catches problems through deliberate destruction. Marge catches problems through sustained attention and process. Bart discovers what's broken; Marge prevents things from breaking in the first place through quality gates. When Marge is doing her job well, Bart finds less to break.
- Marge vs. Lisa: Both care about quality, but differently. Lisa ensures correctness through formal proof and specification. Marge ensures quality through continuous review and maintenance. Lisa is episodic (run before building); Marge is continuous (run always). Lisa defines what "right" looks like; Marge makes sure it stays right over time.
- Marge vs. Homer: Homer tests whether quality survives real-world failure. If Marge's processes are strong enough, Homer can't cause lasting damage. Marge builds the guardrails; Homer tests them.
- Marge vs. Ralph: Ralph builds naively through iteration. Marge reviews what Ralph built. Every PR Ralph produces goes through Marge's review loop. She's the quality gate between Ralph's output and production.
Bart, Lisa, and Homer are episodic — you run them at specific points. Marge never stops. She's the continuous quality loop that prevents the other three from being needed as often. The healthiest codebases are the ones where Marge is bored — because there's nothing to "Hmmmm..." about.
"I'm not sure about the people next door, Homer. They might be... non-compliant with our coding standards."
