{"id":"f63f57fe-2bb2-42d6-a8d5-3c616209f2c6","slug":"mrsnegative","kind":"skill","name":"MrsNegative","summary":"Adversarial code-review persona for AI coding agents. Runs after every diff, flags security/reliability/concurrency issues by severity, and requires a fix for every finding. Portable across Claude Cod","owner":"KnightFiury","repoUrl":"https://github.com/KnightFiury/MrsNegative","license":"Apache-2.0","licenseTier":"permissive","trust":"community","stars":0,"match":null,"fewStars":true,"format":"skill","createdAt":"2026-08-11T04:48:58.000Z","addedAt":"2026-10-31T23:43:13.047Z","logoUrl":"https://avatars.githubusercontent.com/u/86944710?u=7a2e2d7f712a36f60dae4bcf2190b5bdad429e35&v=4","linkOnly":false,"collection":null,"skillPath":null,"categories":["developer-tools"],"tags":["ai-agents","claude-code","code-review","developer-tools","llm","open-code","prompt-engineering","security-tools"],"runtime":"binary","local":true,"cloudCapable":false,"cloudCapability":"unknown","cloudReadyOnPlatform":false,"needsApiKey":false,"reviewed":false,"syncedAt":"2026-10-31T23:43:44.435Z","sample":false,"url":"https://conduits.dev/tools/mrsnegative","language":"JavaScript","transports":["stdio"],"install":{},"requirements":{"env":[],"upstreamMayCharge":false},"tools":null,"readme":"\n\n# Mrs. Negative\n\n> *A skeptical, security-paranoid code-review persona — and verification protocol — for AI coding agents.*\n\n[]()\n[]()\n[]()\n[]()\n[]()\n\n
\n\n---\n\n## Overview\n\n**Mrs. Negative** is a persona for AI coding agents that runs an\nadversarial review after every code change — before the agent moves on or\nreports the task as done. She isn't a linter and she isn't sarcasm for its\nown sake. She's the senior engineer archetype who assumes, by default,\nthat new code is broken, exploitable, or unnecessary — and makes the\nagent prove otherwise, function by function.\n\nShe is also a **verification protocol**. Every finding carries evidence\n(`CONFIRMED` / `LIKELY` / `UNVERIFIED`), an escalation level (L1–L5), an\nimpact statement, a concrete fix, and a named verification step.\n**Suspicion earns investigation. Evidence earns severity.** An unverified\n\"what if\" never gets a `BLOCKING` tag, and a real critical never gets\nhedged into a nitpick because fixing it is annoying.\n\n> \"Do we actually need this, do we?\"\n> \"This'll break on an empty array, won't it?\"\n> \"That's user input going straight into the query, isn't it?\"\n> \"You're not actually confident this handles concurrent writes, are you?\"\n\nShe is talented, not bitter — a teammate you'd want, not a linter that\nshouts about everything with equal volume.\n\n---\n\n## Core Idea\n\nMost AI coding agents default to an eager, \"here's your solution!\"\nposture. That posture is great for velocity and bad for the exact class\nof bugs that don't show up until production: unhandled edge cases,\ninjection points, races, and silently swallowed errors.\n\nMrs. Negative is a counterweight — a fixed persona and checklist injected\ninto the agent's instructions so that *every* code change gets pushed\nthrough the same adversarial lens, consistently, instead of only when\nsomeone remembers to ask for a review.\n\nShe is built to be:\n\n- **Portable** — one plain-text persona definition, no tool-specific\n syntax, that can be pasted into any agent's instructions.\n- **Synchronized** — the adapters and the installable skill are generated\n from `PERSONA.md`, so a checklist change can't silently fail to reach one\n tool.\n- **Automatic** — triggers after every code change, not on request.\n- **Constructive** — every complaint ships with a concrete fix. No\n \"this is bad\" without \"do this instead.\"\n- **Calibrated** — severity-tagged, so a real SQL injection and a\n slightly-unclear variable name don't get the same alarm level.\n- **Verification-first** — findings come with evidence, an escalation\n level, an impact, a fix, and a regression test, so the review is\n checkable by someone other than the agent that produced it.\n\n---\n\n## How She Works\n\n### 1. Trigger\n\nAfter the agent writes or edits any function, endpoint, query, or logic\nblock — before reporting the task as complete — it runs Mrs. Negative's\nreview against **the diff**, not the whole file. Reviewing only what\nchanged keeps her fast and keeps her from re-relitigating code nobody\ntouched.\n\n### 2. Checklist\n\nEvery changed block is run through a fixed set of categories:\n\n| Category | Core question |\n|---|---|\n| Necessity | Do we actually need this, or does something already do it? |\n| Failure modes | What happens on null / empty / zero / huge input? |\n| Security | Is user input reaching a query, shell, or template unsanitized? |\n| Concurrency | What happens if two callers hit this at once? |\n| Error handling | If this fails, does the caller find out, or is it swallowed? |\n| Dependency trust | Does the external call have a timeout? What if it lies to us? |\n| Maintainability | Will the next person know *why* this exists? |\n| Intent | Does this do what the change claims to do — or has a contract been silently narrowed? |\n| Confidence check | Are you actually sure about the risky part, or hoping? |\n| Evidence | What proof backs the finding — CONFIRMED, LIKELY, or UNVERIFIED? |\n\nFull question banks per category live in [`checklists/`](./checklists).\n\n### 3. Severity, evidence, and what actually blocks\n\n| Tag | Meaning | Behavior |\n|---|---|---|\n| 🛑 `BLOCKING` | Real crash, exploit, or data-loss risk on a realistic path | Agent stops and fixes it (or the user explicitly overrides) before continuing |\n| ⚠️ `WORTH-FIXING` | Real risk, not catastrophic | Reported with a fix, agent continues |\n| 💭 `NITPICK` | Style / minor maintainability | Mentioned once, batched, never blocks |\n\nSeverity is earned through an escalation ladder (L1–L5) backed by evidence.\nEvery finding carries an evidence tag — `CONFIRMED` (inspected and\nreproduced), `LIKELY` (airtight reasoning, couldn't execute in-session), or\n`UNVERIFIED` (plausible, couldn't check). `BLOCKING` requires\n`CONFIRMED`/`LIKELY`; an unverified suspicion tops out at `WORTH-FIXING` and\nmust say what couldn't be checked. Dependency claims get their own levels:\n`VERIFIED`, `ASSUMED`, `UNKNOWN`.\n\n### 4. Intent, lifecycle, and modes\n\n- **Intent preservation** — every diff is checked against its stated\n purpose: behavior that contradicts the claim, silently narrowed contracts\n (cited caller-by-caller), and over- or under-implementation.\n- **Finding lifecycle** — findings move `OPEN → FIXED → VERIFIED`, with\n `WONT-FIX` (reasoned rebuttal) and `OVERRIDDEN` (user override) as\n terminal states. Only a `VERIFIED` BLOCKING finding is fully closed.\n- **Modes** — `STRICT` (default, full per-change pass) or `BATCH`\n (mechanical bulk changes: grouped findings, same rules, still logged).\n\n### 5. BLOCKING repair loop\n\nA `🛑` finding stops feature work and runs: **Stop → Investigate → Fix →\nRegression test → Run → Re-review → Continue.** Every `BLOCKING` fix (and\nreal `WORTH-FIXING` fixes) requires a failing-first regression test when the\nproject has test infrastructure — a fix that isn't pinned is a fix that\ndrifts back.\n\n### 6. Tool awareness\n\nMrs. Negative sits *above* the toolchain: the compiler, linter, and test\nrunner own their error classes, and she doesn't re-raise what they already\ncaught — she cites them as evidence. A green suite is the floor, not the\nreview; she adds what tools can't express: intent mismatches, edge-case\nsemantics, design risk, and the triage that decides what actually blocks.\n\n### 7. Output contract\n\nEvery flagged issue ships with a concrete fix, in a fixed format — each\nfinding carries **evidence, impact, a fix, and a verification step**:\n\n```\n🛑 [SECURITY] [CONFIRMED] Building the query by concatenating `userId` — SQL injection risk.\n Evidence: `userId=1' OR '1'='1` returns every row; `1'; DROP TABLE orders; --` drops the table.\n Impact: any caller can read or destroy the whole table.\n → Fix: use a parameterized query instead of string interpolation.\n Verification: run the payload against the endpoint — 0 rows returned, no table dropped.\n```\n\n...and every review closes with one in-character confidence-check line\naimed at the actual risky part of the change — not a generic disclaimer.\n\nSee [`examples/good-review.md`](./examples/good-review.md) for a full\nworked example, and [`examples/over-the-top-review.md`](./examples/over-the-top-review.md)\nfor the failure mode this is explicitly designed to avoid: turning into\nnoise that gets ignored.\n\n---\n\n## Repo Structure\n\n```\nMrsNegative/\n├── LICENSE # Apache 2.0\n├── PERSONA.md # core, tool-agnostic persona — single source of truth, and the ONLY file you edit\n├── .gitignore\n├── .githooks/\n│ └── pre-commit # review-log gate: blocks unresolved 🛑 findings, enforces regeneration sync\n├── checklists/\n│ ├── necessity.md # YAGNI questions\n│ ├── reliability.md # failure-mode questions\n│ ├── security.md # injection / auth / secrets / SSRF / CSRF questions\n│ ├── concurrency.md # race condition questions\n│ ├── error-handling.md # swallowed failures, partial state\n│ ├── maintainability.md # readability + dependency-trust questions\n│ ├── intent.md # \"does this do what it claims\" questions\n│ ├── evidence.md # CONFIRMED / LIKELY / UNVERIFIED questions\n│ └── confidence-check.md # \"are you actually sure?\" questions\n├── adapters/ # GENERATED from PERSONA.md — do not hand-edit\n│ ├── opencode/AGENTS.md # opencode project rules (inlined persona)\n│ ├── codex/codex.md # Codex custom instructions (inlined persona)\n│ └── generic-system-prompt.md # self-contained block for Kimi / any other agent\n├── skills/ # GENERATED — the installable skill (Claude Code)\n│ └── mrs-negative/SKILL.md # frontmatter + inlined persona\n├── fixtures/ # calibration pairs: diff + expected severity tags\n│ ├── README.md # format, grading rules, when to run\n│ ├── security/ # injection, IDOR, SSRF, CSRF\n│ ├── reliability/ # null input, timeouts, swallowed failures\n│ ├── concurrency/ # check-then-act, lost updates, idempotency\n│ ├── necessity/ # YAGNI\n│ ├── maintainability/ # names, magic numbers, emoji\n│ ├── evidence/ # evidence-tag calibration (CONFIRMED / LIKELY / UNVERIFIED)\n│ ├── intent/ # intent preservation, contract narrowing\n│ ├── escalation/ # L1–L5 ladder: suspicion vs. proven critical\n│ ├── lifecycle/ # finding closure: fixed-and-verified, not re-raised\n│ ├── modes/ # STRICT vs. BATCH grouping\n│ ├── confidence-check/ # closing question — grades presence, not tier\n│ └── traps/ # over-tagging temptations — must stay quiet\n├── benchmark/ # formal evaluation: 38 cases, rubric, scoring scripts\n│ ├── README.md # what the benchmark measures, how to run it\n│ ├── rubric.md # 40-point scoring model; evidence/severity definitions\n│ ├── version.md # versioned expected answers + bump policy\n│ ├── cases//*.md # scenario + user request + diff + expected outcome\n│ ├── expected/answers.json # GENERATED by scripts/validate.mjs\n│ ├── results/ # run reports (not committed) — format + template\n│ ├── docs/ # token budget + future evidence-engine design\n│ └── scripts/ # validate.mjs, score.mjs, score.self-test.mjs\n├── examples/\n│ ├── good-review.md # calibrated example: real issues, concrete fixes\n│ └── over-the-top-review.md # anti-pattern: alarmism, no fixes, paralysis\n└── README.md\n```\n\n**Why the adapter layer exists:** every agent tool has a different way of\nloading persistent instructions (Claude Code skills, `AGENTS.md`, Codex\ncustom instructions, a raw system prompt). Rather than maintaining the\npersona separately per tool and watching the copies drift, `PERSONA.md` is\nthe only file that actually defines her behavior, and the adapters plus the\ninstallable skill are **generated** from it: each is `PERSONA.md` inlined\nverbatim under a thin, tool-specific wrapper. A generated copy can't silently\nlose a checklist\ncategory or a severity rule the way a hand-maintained copy can — and because\neach adapter is self-contained, pasting one anywhere works standalone. See\n[Regenerating generated files](#regenerating-generated-files) below.\n\n---\n\n## Installing\n\nMrsNegative ships a single installable skill (`mrs-negative`) under\n`skills/`, which `npx skills add` scans to find installable skills.\n\n```bash\nnpx skills add https://github.com/KnightFiury/MrsNegative\n```\n\nTo target a specific skill by its `name:` field from the SKILL.md\nfrontmatter — not the folder name:\n\n```bash\nnpx skills add https://github.com/KnightFiury/MrsNegative --skill \"mrs-negative\"\n```\n\nFor tools that don't use the `npx skills` CLI, copy\n`skills/mrs-negative/SKILL.md` into your project directly, or paste it into a\nClaude, Codex, or ChatGPT conversation.\n\nThis skill doesn't have prior versions yet — if MrsNegative introduces\nbreaking persona changes in the future, this section will document the\nupgrade path and any version-pinned install name.\n\n---\n\n## Setup\n\nPick the adapter matching your tool and follow it — each is a few lines:\n\n| Tool | Adapter | What to do |\n|---|---|---|\n| Claude Code | [`skills/mrs-negative/SKILL.md`](./skills/mrs-negative/SKILL.md) | `npx skills add https://github.com/KnightFiury/MrsNegative` — see [Installing](#installing) |\n| opencode | [`adapters/opencode/AGENTS.md`](./adapters/opencode/AGENTS.md) | Paste the file's contents into your project's `AGENTS.md` — it's self-contained |\n| Codex | [`adapters/codex/codex.md`](./adapters/codex/codex.md) | Paste into your project's custom instructions |\n| Anything else (Kimi, raw API, custom harness) | [`adapters/generic-system-prompt.md`](./adapters/generic-system-prompt.md) | Paste the self-contained block into your system prompt |\n\nNo build step, no dependencies — this is a set of instruction files, not\na package.\n\n---\n\n## Enabling the pre-commit gate (optional)\n\nThe `.githooks/pre-commit` hook reads the review log (see PERSONA.md's\n\"Review log\" section) and blocks a commit if a staged file's most recent\nlogged entry shows an unresolved `🛑 BLOCKING` finding. It's a backstop,\nnot a live review — it never invokes an agent itself, so it works offline\nand can't fail on a hung API call. It also keeps the regeneration\ninvariant: a commit that stages a `PERSONA.md` change must stage every\nregenerated file alongside it.\n\n```bash\ngit config core.hooksPath .githooks\nchmod +x .githooks/pre-commit\n```\n\nBypass a specific commit with `MRS_NEGATIVE_OVERRIDE=1 git commit ...`.\n\n---\n\n## Regenerating generated files\n\n`PERSONA.md` is the only file you edit. When it changes, regenerate every\ngenerated file in one step — the three adapters under `adapters/` plus the\ninstallable skill at `skills/mrs-negative/SKILL.md`. Never hand-edit a\ngenerated file to keep up with it:\n\n> Regenerate every adapter and the installable skill by inlining the current\n> `PERSONA.md` content verbatim under each file's tool-specific header. Do\n> not paraphrase, shorten, or re-explain `PERSONA.md` — copy it exactly.\n\nThat prompt works with any coding agent, or just do it yourself. After\nregenerating, run the [calibration fixtures](#calibration-fixtures) to\nconfirm the change didn't push severity off its calibration. If you've\nenabled the [pre-commit gate](#enabling-the-pre-commit-gate-optional),\nit will refuse any commit that stages a `PERSONA.md` change without staging\nevery regenerated file alongside it.\n\n---\n\n## Calibration fixtures\n\n`fixtures/` holds pairs of (small diff, expected severity tags) used to check\nthat a given model + adapter combo still produces calibrated reviews. This is\nthe calibration layer for an instruction-only repo, and it's run by hand\nor by agent rather than by CI: paste each fixture through the adapter you're\nabout to ship, compare the severity tags in the output against the expected\noutcome, graded loosely by tier. Run it whenever you change `PERSONA.md` or\nswitch which model an adapter runs against. Format, grading rules, and the\nrun prompt live in [`fixtures/README.md`](./fixtures/README.md).\n\n---\n\n## Benchmark (evaluation)\n\nWhere `fixtures/` checks *calibration* — does the severity language still\nreach the model — `benchmark/` measures *capability*: can Mrs. Negative\nactually verify? It holds 38 versioned cases across security, concurrency,\nreliability, data integrity, user intent, dependency trust, architecture,\nfalse positives, self-review bias, and lifecycle — including a ~26% slice of\ncases that must be answered with **silence**. Each case scores 40 points\nacross 8 dimensions (detection, severity, evidence, intent,\nfalse-positive avoidance, verification, fix, regression test), and a run\nreports precision/recall with **BLOCKING precision measured separately**.\n\n```bash\nnode benchmark/scripts/validate.mjs # deterministic case validation + answers.json\nnode benchmark/scripts/score.self-test.mjs # deterministic check of the scoring logic\nnode benchmark/scripts/score.mjs # score a run (result format in benchmark/results/README.md)\n```\n\nThe benchmark does not replace the calibration fixtures — run both. Full\ndetails, the versioning policy, and the scoring rubric are in\n[`benchmark/README.md`](./benchmark/README.md).\n\n---\n\n## Design Principles\n\n1. **Diff-scoped, not file-scoped.** She reviews what changed, not the whole\n file — the diff under review is her canonical input. Re-auditing\n untouched code on every edit is how reviewers turn into noise machines.\n2. **A complaint without a fix isn't a review.** Every single finding —\n even nitpicks — includes a concrete next action. If she can't articulate\n a fix, she downgrades her confidence in the complaint before raising it.\n3. **Severity is earned, not inflated.** `BLOCKING` is reserved for things\n that would actually hurt someone: exploits, data loss, crashes on\n realistic input. Everything else gets reported and the agent keeps moving.\n4. **Silence is a valid outcome.** If nothing's wrong, she says so in one\n line and stops — she doesn't manufacture a nitpick to look thorough.\n5. **One consistent voice.** She's a specific colleague archetype, not a\n randomized tone generator — that consistency is what makes her outputs\n predictable and easy to skim over time, in chat or in the review log.\n\n---\n\n## Known Limitations\n\n- Severity judgment is still made by the underlying model — \"realistic\n path\" and \"catastrophic\" are calls the LLM makes per review, not a\n deterministic rule engine. Expect some drift across models/providers. The\n [`fixtures/`](./fixtures) calibration suite is the early-warning check for\n this: run it when you change `PERSONA.md` or switch models.\n- Evidence is **self-reported** — a `CONFIRMED` tag means the model says it\n inspected the path, not that the path is safe. The bias-resistance rules\n in `PERSONA.md` exist precisely to make a faked `CONFIRMED` hard to get\n away with, but it is not mechanically verifiable.\n- The finding lifecycle (OPEN→FIXED→VERIFIED) and STRICT/BATCH modes assume\n a stateful, multi-turn conversation. In a stateless single-shot harness\n the lifecycle compresses to OPEN (or FIXED if the fix is in the same\n diff) and BATCH mode is rarely relevant.\n- Diff-only scope means pre-existing issues outside the changed lines are\n only lightly flagged, not fully audited — this is a running-review tool,\n not a full security audit.\n- Persona instructions can be deprioritized by a model under a long or\n crowded system prompt. If she stops firing consistently, check whether\n other instructions are crowding her out, and consider putting the\n adapter file first/last in your instruction stack rather than buried\n in the middle.\n- Tone calibration (BLOCKING vs. NITPICK) depends on the checklist\n examples staying representative — if you extend the checklists, extend\n the calibration examples in `examples/` too, or drift toward alarmism\n is likely.\n\n---\n\n## License & versioning\n\nApache 2.0 — use it, fork it, extend the checklists for your own stack. The\nfull license text is in [`LICENSE`](./LICENSE).\n\nThis repo is under active development. The working copy is version-controlled\n(`main`, synced to `origin`), and a `pre-commit` hook in `.githooks/`\nenforces the review log (blocks commits with an unresolved logged `🛑`) and\nguards the regeneration invariant: `PERSONA.md` is the only file you edit, so\nany commit that changes it must also regenerate every generated file under\n`adapters/` and `skills/`. Enable the hook once per clone as described under\n[Enabling the pre-commit gate](#enabling-the-pre-commit-gate-optional).\n\nThe tree above and all relative links work regardless — the repo doesn't\nrequire git, and the hook is a backstop, not a dependency.\n\n---\n\n\nShe's not being difficult. She's seen the incident review.\n
\n"}