React Doctor is an open source scanner for React projects that are getting more code from AI agents than humans can comfortably review line by line. It runs from the command line, reports issues across state, effects, performance, architecture, security, and accessibility, and can be wired into GitHub Actions for pull request feedback.
Table of Contents
The short version
- React Doctor is published by Million.co under an MIT license and lives at
millionco/react-doctoron GitHub. - The quick start is
npx react-doctor@latest, which runs an audit from a project root without a long setup step. - Its pitch is narrower than a general linter: catch React-specific trouble that may slip through when agents generate code quickly.
- The tool supports agent setup, GitHub Actions annotations, and diff-focused scanning for pull requests.
- Treat it as a second reviewer, not a verdict machine. Static analysis can point at suspicious code, but a team still has to decide what matters.
What happened
Million.co has released React Doctor, a static analysis tool with the blunt tagline: “Your agent writes bad React, this catches it.” The README says it scans React codebases for issues across state and effects, performance, architecture, security, and accessibility. It also says the tool works across common React environments, including Next.js, Vite, TanStack, React Native, and Expo.
The basic command is intentionally small: npx react-doctor@latest. After an audit, teams can run npx react-doctor@latest install to set up agent-facing guidance for tools such as Claude Code, Cursor, Codex, and OpenCode. There is also a GitHub Marketplace action for pull request annotations and comments.
The repository was created in February 2026 and, when checked on May 28, showed more than 11,000 GitHub stars, hundreds of forks, and an MIT license. Those numbers can move quickly, but they are enough to show that this is not a quiet side note in the React tooling world.
Why this is worth watching
React Doctor lands in a gap that many frontend teams are starting to feel. AI coding tools can generate components, hooks, and refactors fast. The slow part is figuring out whether the result quietly introduced a stale effect dependency, an accessibility miss, a performance trap, or an unsafe pattern that only shows up later.
Existing linters already catch plenty of mistakes. The interesting part here is the packaging: React Doctor talks like an audit tool for agent output, not a hand tuned rule set that a team spends a week configuring. That framing matters. If agents are going to submit more pull requests, teams will want cheap automated friction before a human reviewer spends attention.
For readers tracking developer tools, the IT & AI archive has more coverage of how coding agents are changing the review loop. React Doctor fits that same pattern: code generation is becoming normal, so code acceptance needs better guardrails.
React Doctor in practice
The first useful test is simple. Run React Doctor on a real project and read the false positives before wiring it into CI. A scanner that finds every possible smell can still waste a reviewer’s time if the signal is too noisy.
The safer rollout is report-only mode on a few pull requests, then diff scanning for changed files once the team understands the output. The GitHub Action is the obvious place to start because reviewers already live inside pull requests. If the tool catches repeated issues, move those categories into a stronger policy. If a category is mostly noise, keep it as advisory or turn it off if the tool allows that path.
This is especially relevant for teams using agents to touch React Native, Expo, or Next.js code. Those stacks have enough framework-specific behavior that a generic code review checklist often misses practical UI bugs.
What Hacker News readers are arguing about
There is a Hacker News submission for React Doctor, but it had no comments when checked through the public HN APIs. That means there is no real thread to summarize yet.
The absence of debate is its own small warning. React developers should judge the tool on runs against production code, not on launch-day voting. The questions worth asking are concrete: How many findings are actionable? Does it duplicate ESLint, TypeScript, or existing React rules? Can it explain issues well enough for a junior developer or an agent to fix them safely?
The practical read
React Doctor is worth a trial if AI coding tools are already producing React changes in your repo. Start with npx react-doctor@latest on a branch, save the report, and compare the findings with issues your team has actually seen in reviews.
Do not make it a required CI gate on day one. Put it beside ESLint and TypeScript first. If React Doctor repeatedly catches issues that your current checks miss, then promote the narrow categories that proved useful. That is the boring path, but it is also how static analysis becomes part of a workflow instead of another dashboard nobody trusts.