MCPInstall

benchmark-fp-fn-audit

Audit React Doctor against ReactBench or similar diagnostic benchmark corpora for confirmed false positives, false negatives, taxonomy gaps, and verifier artifacts. Use when analyzing rd.log, rd-before.json, rd-after.json, model.patch, result.json, reward/test logs, rule distributions, or when asked to perform a second adversarial pass over React Doctor benchmark findings.

Installs
160
Last 24h
—
Trending rank
—
Security
Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/millionco/react-doctor --skill benchmark-fp-fn-audit
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads benchmark-fp-fn-audit automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

React Doctor benchmark FP/FN audit

Perform an evidence-backed audit of React Doctor diagnostics across a benchmark corpus. Read the complete rule documentation, quantify the distribution of failures, inspect every relevant trial artifact, and independently perform a second pass for additional false positives and false negatives.

Corpus and required resources

For this benchmark, use:

/home/aidenybai/Developer/react-bench-internal/jobs/ReactBench-v1.1-beta-rd-0.9.3-consolidated-final-20260801

Read the complete React Doctor rule documentation from:

https://www.react.doctor/docs/rules

Read these repository review materials when they exist:

/home/aidenybai/Developer/react-bench-internal/docs/aiden-review

Do not treat prior reviews or reports as ground truth. Use them as leads and reverify every claim against the current benchmark revision.

For every inspected trial, locate and read:

  • verifier/model.patch
  • verifier/rd-before.json
  • verifier/rd-after.json
  • verifier/rd.log
  • result.json
  • reward and test logs, discovered with rg --files
  • the task README, prompt, or review material
  • the base and patched source files referenced by the patch

Inspect all trial directories, including primary and verified variants. Normalize duplicate task names and repeated patch hashes before computing task-level statistics.

Evidence rules

Classify findings conservatively:

  • Confirmed FP: a diagnostic is caused by changed code, the behavior is intentional or required, and the rule contract does not apply or its recommended fix would regress behavior.
  • Confirmed FN: a real defect exists in the base or final code, no applicable diagnostic is emitted, and an existing documented rule should cover it.
  • Taxonomy gap: a real defect is present but no existing rule contract reasonably claims to cover it.
  • Harness artifact: the result is caused by malformed output, stale baseline data, verifier behavior, generated files, or an untouched-file diagnostic.
  • Candidate: plausible but missing enough evidence for confirmation.

Do not call a target-task miss a false negative. Do not call a diagnostic a false positive merely because the model failed tests. react_doctor=1 is a gate result, not proof that the code is correct.

Every confirmed finding must cite the exact trial, file, line or code span, rule documentation, diagnostic delta, task behavior, and test result. Separate strict rule misses from out-of-taxonomy gaps.

Workflow

1. Inventory the corpus

Use rg --files to enumerate trial artifacts. Record the benchmark revision, trial count, missing artifacts, duplicate variants, malformed reports, and available task reviews. Do not silently skip incomplete trials.

2. Build diagnostic distributions

Recompute distributions from raw rd.log, rd-before.json, and rd-after.json data. Rank by trial coverage before raw occurrence count. Report:

  • total trials and artifact completeness;
  • reward, test, and React Doctor gate tuple counts;
  • direct NEW or introduced-diagnostic failures;
  • health-mode NEW deltas;
  • health-mode STILL target misses;
  • baseline-to-head rule-count deltas;
  • rule, category, severity, task, repository, and file concentration;
  • changed-file versus untouched-file diagnostics;
  • malformed or truncated reports;
  • primary versus verified-task duplication;
  • successful versus unsuccessful patch comparisons.

Always recompute before relying on a prior summary. Large files can inflate occurrence counts, so show both occurrence count and affected-trial count.

3. Inspect high-impact clusters

Prioritize high-coverage rules and exact introduced-diagnostic failures, especially:

exhaustive-deps
no-giant-component
js-set-map-lookups
no-array-index-as-key
js-combine-iterations
effect-needs-cleanup
no-adjust-state-on-prop-change
button-has-type
prefer-module-scope-static-value
no-static-element-interactions
prefer-module-scope-pure-function
no-pass-data-to-parent
no-pass-live-state-to-parent
no-derived-state
no-ref-current-in-render
click-events-have-key-events
rerender-lazy-ref-init
only-export-components
rerender-lazy-state-init

For each high-impact cluster, inspect representative positives, representative negatives, the largest task concentration, and sibling trials with different outcomes.

4. Perform the independent second pass

Search every trial for additional candidates, not just the known clusters. Apply these heuristics:

  • Separate expensive lazy initialization from cheap empty Map, Set, and equivalent containers.
  • Distinguish render-derived state from async status, media errors, retries, resource lifetimes, subscriptions, and transient UI state.
  • For controlled components, distinguish required parent synchronization from effect loops or unnecessary data forwarding.
  • Follow dangerous HTML values through local aliases, useMemo, wrappers, and helper functions; preserve provenance for trusted serializers such as KaTeX.
  • Distinguish React-docs-blessed previous-prop comparisons from pure derived state and render-phase side effects.
  • Inspect timers, promises, animations, abort signals, subscriptions, and stale closures for races that generic dependency or cleanup warnings do not directly explain.
  • Check focus stealing, focus restoration, controlled selection, keyboard semantics, and ARIA transitions.
  • Check thresholds, aliasing, destructuring, nested callbacks, JSX wrappers, computed properties, and TypeScript syntax.
  • Verify that a diagnostic is on changed code and not a pre-existing issue, generated artifact, fixture, or untouched neighbor.
  • For every proposed FP, find a nearby true-positive counterexample. For every proposed FN, find a nearby case the detector catches.

Known leads to independently recheck, without presuming their classification:

fix-react-rdh-nteract-semiotic-a__5uDDmgx
write-react-glific-glific-fronte__22Gg4p2
fix-react-jumperexchange-jumper__2GBTh7Z
write-react-frankchen021-datasto__2N6xFwQ
fix-react-viclafouch-mui-tel-inp__hQXzJgB
fix-react-floating-ui-floating-u__27iKG4t
fix-react-formidablelabs-victory__2uwi2vz
fix-react-igordanchenko-yet-anot__2GZGZYT
fix-react-rdh-appflowy-io-appflo__vK9uEUy

5. Produce audit artifacts

Write audit-only outputs under the benchmark directory:

audit/rd-0.9.3-second-pass.md
audit/rd-0.9.3-second-pass.jsonl
audit/rd-0.9.3-rule-distribution.tsv

Do not edit React Doctor source, benchmark source, task tests, or verifier data. The JSONL must contain one record per finding with:

{
  "id": "...",
  "classification": "confirmed_fp | confirmed_fn | taxonomy_gap | harness_artifact | candidate",
  "confidence": "high | medium | low",
  "rule": "...",
  "task": "...",
  "trial": "...",
  "file": "...",
  "lines": "...",
  "evidence": "...",
  "baselineDiagnostics": "...",
  "headDiagnostics": "...",
  "testStatus": "...",
  "rdStatus": "...",
  "rationale": "...",
  "recommendedAction": "..."
}

The Markdown report must contain: corpus/methodology, distributions, confirmed FPs, confirmed FNs, taxonomy gaps, harness artifacts, manual-adjudication candidates, prioritized rule fixes, and limitations.

Prioritize fixes using:

affected trial coverage × confidence × reproducibility

Never make a code change as part of this skill unless the user separately requests implementation of a confirmed rule fix.

FAQ

What does the benchmark-fp-fn-audit skill do?

Audit React Doctor against ReactBench or similar diagnostic benchmark corpora for confirmed false positives, false negatives, taxonomy gaps, and verifier artifacts. Use when analyzing rd.log, rd-before.json, rd-after.json, model.patch, result.json, reward/test logs, rule distributions, or when asked to perform a second adversarial pass over React Doctor benchmark findings.

How do I install benchmark-fp-fn-audit?

Run npx skills add https://github.com/millionco/react-doctor --skill benchmark-fp-fn-audit in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/benchmark-fp-fn-audit/ (personal) or .claude/skills/benchmark-fp-fn-audit/ (project).

Which AI agents can use benchmark-fp-fn-audit?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is benchmark-fp-fn-audit safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains benchmark-fp-fn-audit?

It is published by millionco in millionco/react-doctor. It has 160 recorded installs.

More from millionco/react-doctor

View all →

react-doctor

millionco/react-doctor

Use when finishing a feature, fixing a bug, before committing React code, or when the user types /doctor, asks to scan, triage, or clean up React diagnostics. Covers lint, accessibility, bundle size, architecture. Includes a regression check and a full local-triage workflow that fetches the canonical playbook.

Frontend & Design19.4K installs

improve-react

millionco/react-doctor

Survey a whole React codebase as a senior React engineer, using React Doctor's scan as evidence, then produce a prioritized audit and self-contained implementation plans for other agents (or cheaper models) to execute. Read-only on source code — it plans improvements, it does not apply them. Use when the user asks to "improve the React code", "audit this codebase", "make this app faster / more robust", or wants a roadmap of fixes rather than a review of a single diff. For a regression check or a fix-it-now pass, use the react-doctor skill instead.

Frontend & Design2.6K installs

deslop

millionco/react-doctor

Simplify and refine recently modified code while preserving functionality. Use when asked to "deslop", "clean up code", "simplify code", or after making changes that could benefit from refinement.

Frontend & Design521 installs

rule-validate

millionco/react-doctor

Open the skill to read its SKILL.md instructions.

Frontend & Design438 installs

find-similar-functions

millionco/react-doctor

Open the skill to read its SKILL.md instructions.

Frontend & Design429 installs

rule-research

millionco/react-doctor

Open the skill to read its SKILL.md instructions.

Popular security skills

View category →

azure-compliance

microsoft/azure-skills

Run Azure compliance and security audits with azqr plus Key Vault expiration checks. Covers best-practice assessment, resource review, policy/compliance validation, and security posture checks. WHEN: compliance scan, security audit, BEFORE running azqr (compliance cli tool), Azure best practices, Key Vault expiration check, expired certificates, expiring secrets, orphaned resources, compliance assessment.

OfficialSecurity567K installs

minimal-run-and-audit

lllllllama/rigorpilot-skills

Rigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation command and write standardized reprooutputs/ files, including patch notes when repository files changed. Do not use for training execution, initial repo intake, generic environment setup, paper lookup, target selection, hidden scientific-meaning changes, or end-to-end orchestration by itself.

Security477.4K installs

seo-audit

coreyhaines31/marketingskills

When the user wants to audit, review, or diagnose SEO issues on their site. Also use when the user mentions "SEO audit," "technical SEO," "why am I not ranking," "SEO issues," "on-page SEO," "meta tags review," "SEO health check," "my traffic dropped," "lost rankings," "not showing up in Google," "site isn't ranking," "Google update hit me," "page speed," "core web vitals," "crawl errors," "indexing issues," "stuck on page 2," "striking distance keywords," "title tag rewrite," "low CTR," "local SEO," "Google Business Profile," or "map pack." Use this even if the user just says something vague like "my SEO is bad" or "help with SEO" — start with an audit. For building pages at scale to target keywords, see programmatic-seo. For adding structured data, see schema. For AI search optimization, see ai-seo.

Security238.7K installs

firebase-security-rules-auditor

firebase/agent-skills

Audits Firebase (Firestore, Cloud Storage) security rules for vulnerabilities, privilege escalation, role bypasses, create vs update inconsistencies, resource exhaustion, type safety, size limits, and hasOnly ownership checks. Use when auditing/reviewing rules, running red-team rule assessments, or scoring against auditor checklists. Don't use for Firebase CLI (login, deploy), Auth, Crashlytics, Remote Config, or database queries.

OfficialSecurity139.1K installs

audit

pbakaus/impeccable

Run technical quality checks across accessibility, performance, theming, responsive design, and anti-patterns. Generates a scored report with P0-P3 severity ratings and actionable plan. Use when the user wants an accessibility check, performance audit, or technical quality review.

Security81.9K installs

competitors

coreyhaines31/marketingskills

When the user wants to create competitor comparison or alternative pages for SEO and buyer-facing use. Also use when the user mentions 'alternative page,' 'vs page,' 'competitor comparison,' 'comparison page,' '[Product] vs [Product],' '[Product] alternative,' 'competitive landing pages,' 'how do we compare to X,' 'competitor teardown,' 'audit our competitor pages,' 'are our comparison pages out of date,' or 'competitive asset audit.' Use this for any content that positions your product against competitors. Covers four formats: singular alternative, plural alternatives, you vs competitor, and competitor vs competitor. For auditing existing claims (not researching competitors from scratch, which is competitor-profiling; not technical SEO on these pages, which is seo-audit), use the asset audit here. For internal battle cards and sales-specific competitor docs, see sales-enablement.

Security79.3K installs