Skills Agentes

Benchmark Fp Fn Audit

Audita React Doctor contra corpus de benchmark como ReactBench: falsos positivos y negativos confirmados, huecos de taxonomía y artefactos del verificador. Se usa al analizar logs y artefactos de trial o al pedir un segundo pase.

Estrellas
14.7k

en todo el repo

Actividad
56

0–100, la ruta de este skill

Actualizado
el mes pasado

último commit aquí

Commits
1

últimos 90 días

Contexto
2k tok

94 tok en reposo

Paquete
3 archivos

10 KB

Instalar

Funciona con cualquier agente que lea SKILL.md

npx -y skills add millionco/react-doctor --skill benchmark-fp-fn-audit --agent claude-code

Se instala solo en este repositorio.

Este skill makes network requests.

Qué hace

  • Audita React Doctor contra corpus de benchmark como ReactBench en busca de falsos positivos y falsos negativos confirmados, huecos de taxonomía y artefactos del verificador.
  • Obliga a leer la documentación completa de reglas, cuantificar la distribución de fallos e inspeccionar cada artefacto de trial, sin tratar revisiones previas como verdad.
  • Clasifica de forma conservadora: FP confirmado, FN confirmado, hueco de taxonomía, artefacto del harness o candidato, y cada hallazgo confirmado cita trial, archivo, línea, regla y resultado de test.
  • Incluye un segundo pase adversarial independiente con heurísticas para distinguir estado derivado de render de estado asíncrono, sincronización de padres, valores HTML peligrosos, etc.
  • Escribe salidas de solo auditoría (`.md`, `.jsonl`, `.tsv`) bajo el directorio del benchmark y nunca toca el código de React Doctor, del benchmark ni de los tests.

Úsalo cuando

  • Se analizan `rd.log`, `rd-before.json`, `rd-after.json`, `model.patch`, `result.json` o logs de reward y tests.
  • Se pide un segundo pase adversarial sobre los hallazgos de un benchmark de React Doctor.

No lo uses cuando

    Qué lo activa

    Di cualquiera de estas frases y el agente debería cargar este skill.

    • Audita los resultados de ReactBench para falsos positivos y negativos
    • Haz un segundo pase adversarial sobre estos trials de benchmark
    • Cuantifica la distribución de fallos por regla en este corpus

    SKILL.md

    En inglés

    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.

    Reproducido de millionco/react-doctor bajo licencia NOASSERTION. Leer esta página en markdown.

    Archivos

    3 archivos en el paquete. Solo se lee SKILL.md al activarse — las referencias se cargan si el skill decide que las necesita.

    Antes de instalar

    Necesita acceso al directorio del corpus de benchmark y a la documentación de reglas en `react.doctor/docs/rules`; usa `rg --files` para enumerar artefactos.

    Detalles

    Creador
    millionco
    Categoría
    Testing y QA
    Licencia
    NOASSERTION
    Recursos incluidos
    referencias
    Código fuente
    Ver SKILL.md

    Etiquetas

    Más de millionco/react-doctor

    Este repo incluye 16 skills. Si instalas uno, normalmente ya tienes los demás.

    Escanea bases de código React en busca de problemas de seguridad, rendimiento, corrección y arquitectura, y da una puntuación de salud de 0 a 100. Incluye chequeo de regresión y un flujo completo de triage local con `/doctor`.

    Costo de contexto al activarse
    1k tok
    Tamaño del paquete
    2 archivos
    Última actualización
    hace 15 días
    testing qa

    Compara los diagnósticos de React Doctor de un pull request contra su base con Daytona. Se usa para correr parity, comprobar regresiones de diagnósticos en un PR o reportar diagnósticos añadidos y quitados.

    Costo de contexto al activarse
    4.1k tok
    Tamaño del paquete
    17 archivos
    Última actualización
    hace 28 días
    testing qa

    Audita y arregla apps de Three.js y React Three Fiber: rendimiento del frame-loop, fugas de memoria de GPU, corrección del grafo de escena y defectos visuales como z-fighting, shadow acne, espacio de color erróneo y resize roto.

    Costo de contexto al activarse
    2.3k tok
    Tamaño del paquete
    1 archivo
    Última actualización
    hace 15 días
    herramientas desarrollo

    Fuzz

    14.7k

    Somete a fuzzing las reglas de React Doctor con `@react-doctor/fuzz` para hallar crashes, lentitud, falsos positivos y diagnósticos sensibles a mutaciones. Se usa tras pasar los tests de la regla o al confirmarse un falso positivo nuevo.

    Costo de contexto al activarse
    839 tok
    Tamaño del paquete
    1 archivo
    Última actualización
    el mes pasado
    testing qa

    Diagnostica el rendimiento de React en tiempo de ejecución con trazas de React Doctor, marcado de renders en vivo, Long Animation Frames y evidencia de renders por componente. Se invoca como `/performance`.

    Costo de contexto al activarse
    1.2k tok
    Tamaño del paquete
    1 archivo
    Última actualización
    hace 15 días
    testing qa

    Ejecuta un bucle local y acotado de React Doctor Evals contra un cambio de regla sin commitear. Se usa tras pasar los tests de la regla, al inspeccionar hits de código abierto o cuando rule-validate pide evidencia local antes de la parity.

    Costo de contexto al activarse
    509 tok
    Tamaño del paquete
    1 archivo
    Última actualización
    el mes pasado
    testing qa

    Skills relacionados

    Fuzz

    14.7k

    Somete a fuzzing las reglas de React Doctor con `@react-doctor/fuzz` para hallar crashes, lentitud, falsos positivos y diagnósticos sensibles a mutaciones. Se usa tras pasar los tests de la regla o al confirmarse un falso positivo nuevo.

    Costo de contexto al activarse
    839 tok
    Tamaño del paquete
    1 archivo
    Última actualización
    el mes pasado
    testing qa

    Diagnostica el rendimiento de React en tiempo de ejecución con trazas de React Doctor, marcado de renders en vivo, Long Animation Frames y evidencia de renders por componente. Se invoca como `/performance`.

    Costo de contexto al activarse
    1.2k tok
    Tamaño del paquete
    1 archivo
    Última actualización
    hace 15 días
    testing qa

    Ejecuta un bucle local y acotado de React Doctor Evals contra un cambio de regla sin commitear. Se usa tras pasar los tests de la regla, al inspeccionar hits de código abierto o cuando rule-validate pide evidencia local antes de la parity.

    Costo de contexto al activarse
    509 tok
    Tamaño del paquete
    1 archivo
    Última actualización
    el mes pasado
    testing qa