React Doctor: guía práctica para detectar y corregir errores en React

¿Cuántas veces has abierto un proyecto React que lleva meses en producción y has sentido que algo no huele bien? Código que funciona, sí, pero con esa sensación de que hay cosas escondidas que se van a romper en el peor momento posible.

Pues alguien ha construido una herramienta que destapa todo eso con una sola línea en la terminal:

npx -y react-doctor@latest .

React Doctor analiza tu proyecto React y te devuelve una puntuación de 0 a 100. Un chequeo médico completo de tu código: seguridad, rendimiento, arquitectura, tamaño de bundle, accesibilidad, código muerto y más de 60 reglas de buenas prácticas.

Si ya conocías esta herramienta, te interesa lo que viene ahora. Porque desde su lanzamiento ha cambiado de piel: ya no es solo una CLI que ejecutas a mano cuando te acuerdas. Ahora vive dentro de tu flujo de trabajo.

🆕 Lo más importante de esta actualización: React Doctor ya tiene una GitHub Action oficial que se ejecuta en cada pull request, publica la puntuación, marca las regresiones contra main y comenta línea a línea. La accesibilidad ha subido a categoría de primer nivel y el enfoque hacia los agentes de código se ha vuelto el centro de todo.

En este artículo te cuento todo lo que necesitas saber para sacarle partido:

• Cómo funciona por dentro y qué analiza
• Las categorías de reglas que aplica (con la accesibilidad recién ascendida)
• Cómo configurarlo para tu proyecto
• Cómo ponerlo a revisar cada pull request con la GitHub Action
• Cómo integrarlo con agentes de IA
• Los errores más comunes que detecta (y cómo solucionarlos)

Empezamos.

¿Quién hay detrás? ¶

React Doctor es un proyecto open source de Aiden Bai, el mismo creador de Million.js y React Scan. Lo publica bajo la organización millionco en GitHub y tiene licencia MIT. No es un plugin de ESLint al uso, sino una herramienta de diagnóstico independiente que combina linting propio con detección de código muerto.

El proyecto ha crecido rápido: supera ya las 5.000 estrellas en GitHub y la lista de empresas que lo usan en producción no para de aumentar. Hasta Miguel Ángel Durán (midudev) lo ha recomendado abiertamente como herramienta que detecta antipatrones de React: useEffect innecesarios, errores de accesibilidad y prop drilling que podrías evitar con Context.

La filosofía sigue intacta: un solo comando, sin configuración previa, que te dé una foto nítida de la salud de tu proyecto React. Lo que ha cambiado es para quién está pensada esa foto. El eslogan oficial lo deja claro: tu agente escribe React regular, y esto lo caza.

Ejecución básica: tu primera consulta al doctor ¶

Lo primero. Abre la terminal en la raíz de tu proyecto React y lanza esto:

npx -y react-doctor@latest .

El punto al final indica el directorio actual. Puedes sustituirlo por la ruta que quieras.

React Doctor detecta de forma automática tu framework (Next.js, Vite, Remix, Astro…), la versión de React y si usas el compilador de React. Funciona con cualquier base de código React 18 o 19, y recorre tus archivos fuente sin que tengas que tocar la configuración del framework. Si estás evaluando alternativas a Next.js como TanStack Start, la herramienta se adapta al framework que uses. A partir de ahí, activa o desactiva reglas según tu configuración real. No va a quejarse de algo específico de Next.js si tu proyecto usa Vite.

El resultado es una puntuación y un listado de diagnósticos. Algo así:

  ┌─────┐
  │ • • │
  │  ─  │
  └─────┘

69 / 100 Needs work
█████████████████████░░░░░░░░░
64 errors 418 warnings across 178 files

La escala es sencilla:

• 75 o más: Great. Tu proyecto está en buena forma.
• 50 a 74: Needs work. Hay trabajo pendiente.
• Menos de 50: Critical. Es hora de ponerse las pilas.

Si quieres ver el detalle de cada archivo y línea afectada, añade --verbose:

npx -y react-doctor@latest . --verbose

Y si solo necesitas la puntuación numérica (útil para scripts de CI), tienes --score:

npx -y react-doctor@latest . --score

🔍 Dato importante: React Doctor ejecuta dos pasadas en paralelo. La primera es un lint con más de 60 reglas propias. La segunda detecta código muerto: archivos sin usar, exports huérfanos, tipos que no se importan en ningún sitio y duplicados. Todo eso pesa en la puntuación final.

Las opciones de la CLI ¶

La interfaz de línea de comandos tiene más opciones de las que parece a simple vista:

Usage: react-doctor [directory] [options]

Options:
  -v, --version     muestra la versión
  --no-lint         salta el análisis de linting
  --no-dead-code    salta la detección de código muerto
  --verbose         muestra detalle por archivo y línea
  --score           muestra solo la puntuación
  -y, --yes         salta prompts, analiza todos los proyectos del workspace
  --project <name>  selecciona un proyecto del workspace (separados por coma)
  --diff [base]     analiza solo los archivos que han cambiado respecto a la rama base
  --ami             activa los prompts relacionados con Ami
  --fix             abre Ami para auto-corregir los problemas
  -h, --help        muestra la ayuda

Hay una novedad aquí que conviene anotar. Ahora existen dos banderas separadas para trabajar con Ami, el agente de Million: --ami activa los prompts de Ami sin más, y --fix va directo a abrir Ami para que auto-corrija todos los problemas detectados. Antes todo iba por la misma puerta; ahora tienes ese paso intermedio.

La opción --diff merece mención especial. Cuando trabajas en una rama de feature y solo quieres ver qué problemas introduces tú, sin cargar con la deuda técnica heredada, este flag analiza exclusivamente los archivos que han cambiado respecto a la rama base. Guárdala en la cabeza, porque es la pieza que hace que la integración con CI cobre sentido.

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter

¿Qué analiza? Las categorías de reglas ¶

Aquí es donde React Doctor se pone serio. No estamos ante un linter genérico. Cada regla está diseñada para detectar problemas específicos del ecosistema React.

1. Estado y efectos ¶

Esta es la categoría más densa y, probablemente, la más valiosa. React Doctor detecta varios antipatrones que todos hemos cometido alguna vez:

• Estado derivado en useEffect: si tu efecto solo llama a setState con valores calculados a partir de las dependencias, no necesitas un efecto. Calcula el valor durante el renderizado.
• fetch dentro de useEffect: no es que esté prohibido, pero existen mejores alternativas como react-query, SWR o un componente de servidor.
• setState en cascada: tres o más llamadas a setState dentro de un mismo useEffect son señal de que necesitas useReducer.
• useState inicializado con props: si el estado se inicializa con una prop y debería mantenerse sincronizado, mejor derivarlo durante el render.
• Inicialización perezosa sin lazy: useState(computeValue()) se ejecuta en cada render. Lo correcto es useState(() => computeValue()).

// ❌ Esto se ejecuta en cada render
const [data, setData] = useState(parseExpensiveData());

// ✅ Esto solo se ejecuta una vez
const [data, setData] = useState(() => parseExpensiveData());

También detecta cuando usas un useEffect como si fuera un event handler (el efecto entero depende de un booleano que cambia y ejecuta lógica condicionalmente). La solución es mover esa lógica al manejador del evento real. Y vigila las trampas clásicas que arrastra todo el mundo: dependencias incompletas, capturas de stale closure, efectos sin función de limpieza y async sin cleanup que dejan promesas colgando.

2. Rendimiento ¶

React Doctor entiende de rendimiento a nivel de framework:

• useMemo innecesario: envolver una expresión trivial (una suma, una propiedad, un literal) en useMemo es contraproducente. La propia memoización cuesta más que el cálculo.
• Props inline en componentes con memo: si envuelves un componente con React.memo() pero luego le pasas funciones, objetos o arrays creados en línea, el memo no sirve para nada. Cada render genera una nueva referencia.
• Animación de propiedades de layout: animar width, height, margin o padding con Framer Motion provoca recalculaciones de layout en cada frame. La alternativa es usar transform o el prop layout.
• transition: “all”: anima todas las propiedades CSS, incluidas las de layout. Mejor especificar cuáles.
• will-change permanente: dejarlo fijo en el estilo consume memoria GPU sin necesidad. Aplica solo durante la animación.
• Blur excesivo: un blur() de más de 10px escala en coste con el radio y el tamaño del elemento. En móvil puede superar la memoria de la GPU.

3. Arquitectura ¶

Problemas estructurales que se acumulan con el tiempo:

• Componentes gigantes: si un componente supera las 300 líneas, React Doctor avisa. Es hora de dividirlo.
• Componentes anidados: definir un componente dentro de otro es un error clásico. En cada render del padre se crea una nueva instancia del hijo, destruyendo todo su estado interno.
• Funciones render en línea: llamar a renderHeader() o renderList() dentro del JSX en lugar de extraer componentes independientes rompe la reconciliación de React.
• Prop drilling: pasar la misma prop a través de varias capas de componentes que no la usan es un olor de diseño. La herramienta lo señala y te empuja hacia Context.

⚠️ Definir un componente dentro de otro es uno de los errores más frecuentes y más difíciles de detectar a simple vista. Cada render del padre destruye y recrea el componente hijo completo, incluyendo su estado, sus refs y sus efectos. React Doctor lo pilla al vuelo.

4. Tamaño de bundle ¶

Tu aplicación puede pesar mucho más de lo necesario:

• Imports de barrel files: importar desde ./components/index impide el tree-shaking. Importa directamente desde el módulo fuente.
• Lodash completo: import _ from 'lodash' trae toda la librería. Importa función por función: import debounce from 'lodash/debounce'.
• moment.js: pesa más de 300kb. date-fns o dayjs hacen lo mismo con una fracción del tamaño.
• Librerías pesadas sin code splitting: Monaco Editor, Recharts, React PDF, Chart.js… Si las importas estáticamente, cargan en el bundle principal. Usa React.lazy() o next/dynamic.
• Framer Motion completo: importar motion trae ~30kb. Con LazyMotion y el import de m, recortas ese peso.

5. Seguridad ¶

Dos reglas directas y críticas:

• eval() y new Function(): inyección de código. Sin excusas.
• Secretos en el código cliente: React Doctor detecta variables con nombres como API_KEY, SECRET, TOKEN o PASSWORD que contienen cadenas sospechosas. También reconoce patrones de tokens de Stripe, AWS, GitHub, GitLab, Slack y OpenAI.

// ❌ React Doctor lo detecta
const API_KEY = "sk-proj-abc123456789...";

// ✅ Usa variables de entorno
const apiKey = process.env.NEXT_PUBLIC_API_KEY;

6. Corrección ¶

Errores que no rompen la compilación pero sí el comportamiento:

• Index como key: usar el índice del array como key en listas provoca bugs cuando los elementos se reordenan, se filtran o se eliminan.
• preventDefault en formularios: e.preventDefault() en un <form> significa que el formulario no funciona sin JavaScript. Un componente de servidor o una server action serían más robustos.
• Renderizado condicional con .length: {items.length && <List />} renderiza el número 0 cuando la lista está vacía. La solución es {items.length > 0 && <List />}.

7. Rendimiento JavaScript ¶

Reglas que van más allá de React y aplican a cualquier código JavaScript:

• Iteraciones encadenadas: .filter().map() recorre el array dos veces. Un solo reduce() o un for...of lo hace en una pasada.
• [...array].sort(): ahora existe array.toSorted() (ES2023), que es inmutable por diseño.
• RegExp dentro de bucles: crear una expresión regular en cada iteración es desperdicio puro. Elévala a nivel de módulo.
• array.sort()[0] para el mínimo: Math.min(...array) es O(n) frente al O(n log n) del sort.
• includes/indexOf en bucles: son O(n) por llamada. Convierte a un Set para búsquedas O(1).
• Awaits secuenciales independientes: si tres awaits no dependen entre sí, Promise.all() los ejecuta en paralelo.

8. Reglas específicas de Next.js ¶

Aquí React Doctor brilla con 17 reglas dedicadas:

• <img> en vez de next/image
• <a> con href interno en vez de next/link
• Componentes cliente asíncronos (no es posible)
• useSearchParams() sin <Suspense>
• fetch en useEffect dentro de páginas (debería ser server component)
• Páginas sin export de metadata (mal para SEO)
• Redirects en el cliente con router.push dentro de useEffect
• redirect() dentro de try-catch (lanza un error especial que Next.js maneja)
• next/image con fill pero sin sizes
• <script> nativo en vez de next/script
• Google Fonts vía <link> en vez de next/font
• CSS vía <link> en vez de import
• Polyfills externos innecesarios
• next/head en el App Router
• GET handlers con side effects (riesgo de CSRF)

9. React Native ¶

Para proyectos de React Native, React Doctor incluye reglas específicas:

• Texto fuera de <Text> (crash garantizado)
• Módulos eliminados de React Native (como AsyncStorage, Clipboard, WebView…)
• Dimensions.get() que no se actualiza con la rotación de pantalla
• renderItem inline en FlatList (nueva función en cada render)
• Propiedades de sombra legacy en lugar de boxShadow
• Animated del JS thread en vez de react-native-reanimated

10. Servidor ¶

Dos reglas para server actions:

• Autenticación ausente: si exportas una server action sin llamar a auth(), getSession() o funciones similares al principio, React Doctor avisa. Un server action sin autenticación es una puerta abierta.
• Logging bloqueante: console.log() o analytics.track() dentro de server actions deberían usar after() para no bloquear la respuesta.

11. Accesibilidad ¶

Esta categoría no es del todo nueva, pero sí ha ganado galones. En las primeras versiones quedaba diluida entre el resto de reglas; ahora aparece como una categoría de primer nivel dentro de las pasadas de análisis, al mismo rango que rendimiento o seguridad.

¿Qué significa eso para ti? Que las regresiones de accesibilidad ya no pasan de puntillas. La herramienta vigila los descuidos típicos que se cuelan cuando vas con prisa o cuando un agente genera el JSX sin pensar en quien navega con teclado o lector de pantalla.

💡 La accesibilidad es de esas cosas que todos juramos cuidar y que nadie revisa en cada PR. Tenerla integrada en la puntuación, junto al rendimiento y la seguridad, cambia el incentivo: ya no es un extra que harás “cuando haya tiempo”, es parte de la nota.

React Doctor en cada pull request ¶

Aquí está el cambio que de verdad transforma cómo se usa la herramienta. React Doctor ya no es solo algo que ejecutas cuando te acuerdas: ahora trae una GitHub Action oficial que revisa cada pull request de forma automática.

¿Qué hace exactamente? Se ejecuta en cada PR, publica la puntuación nueva, marca las regresiones contra la rama main y comenta línea a línea sobre el código que introduce los problemas. Es decir, convierte el chequeo médico en algo continuo en lugar de una visita puntual.

La configuración mínima cabe en unas pocas líneas de tu workflow:

- uses: actions/checkout@v5
  with:
    fetch-depth: 0 # necesario para el modo --diff
- uses: millionco/react-doctor@main
  with:
    diff: main
    github-token: ${{ secrets.GITHUB_TOKEN }}

Dos detalles importan aquí.

El primero es fetch-depth: 0 en el checkout. Sin el historial completo, el modo --diff no puede comparar tu rama contra main. Si lo olvidas, la Action no sabrá qué archivos has tocado tú y qué deuda viene heredada.

El segundo es el github-token. Cuando lo defines en eventos de tipo pull_request, la Action publica sus hallazgos como un comentario en el propio PR. Sin token, sigue funcionando, pero te pierdes la parte más útil: el feedback dentro de la conversación de la revisión.

Estos son los parámetros que acepta:

La Action expone una salida score con la puntuación de 0 a 100. Puedes engancharla en pasos posteriores de tu workflow: hacer que el job falle si baja de cierto umbral, escribirla en un badge, registrarla en un panel interno…

🛡️ La combinación de --diff con el comentario automático en el PR es la jugada ganadora. Solo se analizan los archivos que toca cada cambio, así que no arrastras la deuda técnica histórica del repo. Cada autor responde por lo que introduce, no por lo que ya estaba ahí. Es la diferencia entre una herramienta que regaña y una que enseña.

Hay incluso quien ha montado un pequeño agente que ejecuta React Doctor sobre cada PR y “achicharra” al autor con las regresiones de calidad respecto a main. Suena a broma, pero ese tipo de barreras automáticas son justo lo que mantiene la calidad de una base de código cuando varias personas (y varios agentes) escriben a la vez.

Configuración personalizada ¶

No todas las reglas aplican a todos los proyectos. React Doctor permite personalización mediante un archivo react-doctor.config.json en la raíz:

{
  "ignore": {
    "rules": ["react/no-danger", "jsx-a11y/no-autofocus", "knip/exports"],
    "files": ["src/generated/**"]
  }
}

También puedes usar la clave "reactDoctor" en tu package.json:

{
  "reactDoctor": {
    "ignore": {
      "rules": ["react/no-danger"],
      "files": ["**/*.test.tsx"]
    }
  }
}

Si existen ambos, react-doctor.config.json tiene prioridad. Y recuerda: las banderas de la CLI siempre mandan sobre lo que pongas en el archivo de configuración.

Las opciones disponibles son:

• ignore.rules: reglas a silenciar con formato plugin/rule (por ejemplo react/no-danger, knip/exports, knip/types)
• ignore.files: patrones glob de archivos a excluir
• lint: activar o desactivar el linting (equivale a --no-lint)
• deadCode: activar o desactivar la detección de código muerto (equivale a --no-dead-code)
• verbose: mostrar detalle por archivo
• diff: forzar modo diff (true), fijar una rama base ("main") o desactivar la detección automática (false)

Ese último matiz del diff es nuevo y útil: si por lo que sea no quieres que React Doctor intente adivinar la rama base, le pones false y se acabó la magia automática.

Integración con agentes de IA ¶

Una de las ideas más potentes de React Doctor es que está diseñado para trabajar con agentes de código. De hecho, esta es ahora la apuesta central del proyecto: enseñar a tu agente a no escribir React malo en primer lugar.

Un solo comando instala las “skills” de React Doctor en tu agente favorito:

curl -fsSL https://react.doctor/install-skill.sh | bash

Compatible con Cursor, Claude Code, Amp Code, Codex, Gemini CLI, OpenCode, Windsurf y Antigravity. Si ya usas Claude Code, consulta estos consejos prácticos para sacarle el máximo partido.

¿Qué significa esto en la práctica? Que tu agente de IA aprende las más de 47 reglas de buenas prácticas que la skill recoge y las aplica cuando genera o revisa código. Ojo al matiz: el lint completo de la CLI ejecuta 60+ reglas, mientras que la skill condensa las 47+ buenas prácticas que tu agente debe interiorizar. No es solo un linter que te dice lo que falla: es un profesor que enseña a tu asistente a no cometer esos errores en primer lugar.

🤖 Si ya trabajas con agentes de IA para programar, esta integración es casi obligatoria. Enseñar a tu agente las buenas prácticas de React antes de que escriba código es mucho más eficiente que corregirlo después. Y combinado con la GitHub Action, cierras el círculo: el agente escribe mejor, y lo que se le escape se caza en el PR.

📚 Las skills no son exclusivas de Claude Code. Si eres programador y quieres entender qué son, cómo funcionan y cómo aprovecharlas en tu flujo de trabajo con cualquier agente, te lo explico a fondo en este artículo: Skills para programadores y agentes de IA.

API programática ¶

Para integraciones personalizadas, React Doctor ofrece una API de Node.js:

import { diagnose } from "react-doctor/api";

const result = await diagnose("./path/to/project");

// Puntuación general
console.log(result.score);
// { score: 82, label: "Good" }

// Lista de diagnósticos
console.log(result.diagnostics);

// Info del proyecto detectado
console.log(result.project);

La función diagnose acepta un segundo argumento opcional para afinar qué pasadas se ejecutan:

const result = await diagnose(".", {
  lint: true,     // ejecuta el análisis de linting (por defecto: true)
  deadCode: true, // ejecuta la detección de código muerto (por defecto: true)
});

Cada diagnóstico tiene esta forma:

interface Diagnostic {
  filePath: string;   // Ruta del archivo
  plugin: string;     // Plugin que lo detecta
  rule: string;       // Nombre de la regla
  severity: "error" | "warning";
  message: string;    // Descripción del problema
  help: string;       // Sugerencia de solución
  line: number;       // Línea del archivo
  column: number;     // Columna
  category: string;   // Categoría (performance, security...)
}

Esto abre la puerta a construir dashboards internos, integrarlo con tu pipeline de CI/CD o crear reportes personalizados.

Cómo funciona por dentro ¶

He revisado el código fuente del plugin de reglas propias y hay detalles interesantes de su arquitectura interna.

Cada regla es un visitor del AST. El patrón es el mismo que usa ESLint: una función create recibe un contexto y devuelve un objeto con métodos que se ejecutan al visitar nodos del árbol sintáctico. Por ejemplo, la regla noArrayIndexAsKey visita nodos JSXAttribute y busca atributos key cuyo valor sea un identificador con nombre index, idx o i.

Las constantes están centralizadas. Un archivo constants.ts de unas 250 líneas define todos los umbrales, patrones y listas que usan las reglas. Un componente “gigante” son más de 300 líneas. El umbral de setState en cascada es 3 llamadas. Un secreto sospechoso tiene al menos 8 caracteres. Todo está parametrizado y con nombres descriptivos en SCREAMING_SNAKE_CASE.

Las utilidades compartidas son elegantes. Un helper createLoopAwareVisitors permite definir reglas que solo se activan dentro de bucles (como la de includes() en un loop). Otro helper walkAst recorre cualquier nodo para buscar patrones profundos. Y findSideEffect detecta efectos secundarios como llamadas a cookies().set(), fetch() con método POST, o métodos de base de datos como .insert() o .delete().

El análisis es determinista, y ese detalle no es menor. En un mundo donde los agentes generan código a toda velocidad, tener una herramienta que da siempre el mismo veredicto sobre el mismo código es justo el contrapeso que necesitas. La IA propone; el análisis estático confirma si aquello aguanta.

Proyectos conocidos bajo el microscopio ¶

React Doctor publica un leaderboard con proyectos open source populares. Algunos resultados:

Que proyectos tan conocidos como Supabase o Sentry estén por debajo de 75 no significa que sean malos proyectos. Significa que la deuda técnica es real y que las buenas prácticas de React son más difíciles de mantener de lo que parece cuando el código crece.

Un flujo de trabajo práctico ¶

¿Cómo integrar React Doctor en tu día a día? Te propongo un enfoque progresivo:

1. Primera pasada: lanza el comando sin más y revisa la puntuación general. No intentes arreglarlo todo de golpe.
2. Prioriza por severidad: los errores pesan más que los warnings. Empieza por los errores de seguridad y corrección.
3. Configura las excepciones: si hay reglas que no aplican a tu proyecto, siléncialas en el archivo de configuración.
4. Mete la GitHub Action en CI: añade la Action con diff: main para que cada pull request se analice solo en sus cambios y comente las regresiones. Así no arrastras la deuda técnica existente y cada autor responde por lo suyo.
5. Instala el skill en tu agente: si usas Claude Code, Cursor o cualquier otro agente, la integración del skill previene errores antes de que lleguen al repositorio.

💡 Un buen punto de partida es ejecutar React Doctor con --verbose y filtrar solo los errores de la categoría “estado y efectos”. Son los que más impacto tienen en el comportamiento real de tu aplicación y, en muchos casos, los más fáciles de corregir.

Cómo puntúa ¶

El sistema de puntuación es transparente. React Doctor asigna más peso a los errores que a los warnings. La fórmula tiene en cuenta el número total de diagnósticos, la severidad de cada uno y la cantidad de archivos afectados.

Esto significa que un proyecto con 5 errores graves puede puntuar peor que otro con 50 warnings menores. Tiene sentido: un secreto expuesto en el código cliente es más urgente que un useMemo innecesario.

La escala es intuitiva. Por encima de 75 estás en buena forma. Entre 50 y 74 hay trabajo que hacer. Por debajo de 50, el proyecto necesita atención seria. Que no te asuste una nota baja: incluso proyectos tan consolidados como Sentry o cal.com están por debajo de 75.

Y ahora que la puntuación viaja contigo en cada PR, la nota deja de ser un dato anecdótico de un día concreto. Se convierte en una línea que sube o baja con cada cambio, visible para todo el equipo.

Conclusión ¶

React Doctor no viene a sustituir a ESLint. Viene a complementarlo con reglas que ESLint no tiene y que son específicas del ecosistema React moderno: Server Components, Server Actions, Next.js App Router, React Native, Framer Motion, accesibilidad, código muerto… Si quieres ver cómo se comparan estas tecnologías en la práctica, la comparativa de los 5 mejores stacks para desarrollo web analiza en profundidad React Server Components frente a otras opciones.

Pero el verdadero salto de esta nueva etapa no está en las reglas. Está en dónde vive la herramienta.

Antes la usabas a mano. Ahora se ejecuta en cada commit, comenta cada PR y enseña a tu agente a escribir mejor desde el principio. Un solo comando para empezar, una Action para no soltarla nunca y un skill para que la IA aprenda la lección antes de equivocarse.

Si trabajas con React a diario, merece la pena dedicar 5 minutos a pasar el doctor. A lo mejor te llevas una sorpresa con la nota.

npx -y react-doctor@latest .