react-doctor
Run after making React changes to catch issues early. Use when reviewing code, finishing a feature, or fixing bugs in a React project.
74
68%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./config/claude/skills/react-doctor/SKILL.mdQuality
Discovery
49%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description provides explicit 'when' triggers which is a strength, but it is critically vague about what the skill actually does — 'catch issues early' could mean running tests, linting, type checking, building, or any number of things. The lack of concrete actions and the generic nature of the triggers create high conflict risk with other quality-assurance or code-review skills.
Suggestions
Replace 'catch issues early' with specific concrete actions the skill performs, e.g., 'Runs ESLint, TypeScript type checking, and unit tests on React components'.
Add more distinctive trigger terms that differentiate this from general code review or testing skills, e.g., mention specific tools or file types like '.tsx', '.jsx', 'component tests', 'React hooks'.
Clarify the unique niche — is this a test runner, a linter, a build checker? Specificity will reduce conflict with other skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description says 'catch issues early' and 'Run after making React changes' but does not list any concrete actions like 'run linting', 'execute tests', 'check for type errors', etc. The actions are vague — 'catch issues' is abstract. | 1 / 3 |
Completeness | It answers both 'what' (run after making React changes to catch issues early) and 'when' (when reviewing code, finishing a feature, or fixing bugs in a React project) with explicit trigger scenarios. | 3 / 3 |
Trigger Term Quality | Includes 'React', 'code', 'feature', 'bugs' which are somewhat relevant keywords users might say. However, it lacks specific terms like 'lint', 'test', 'type check', 'build', 'CI', or other natural trigger terms that would clarify what kind of checking is being done. | 2 / 3 |
Distinctiveness Conflict Risk | 'Catch issues early' and 'reviewing code' are extremely generic and could overlap with linting skills, testing skills, code review skills, static analysis skills, or any quality-checking tool. There is no clear niche established. | 1 / 3 |
Total | 7 / 12 Passed |
Implementation
87%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a concise, actionable skill that provides a clear single command for running react-doctor. Its main strength is extreme brevity while remaining useful. The workflow section could be slightly more explicit about interpreting output and prioritizing fixes, but for a simple tool-invocation skill, it performs well.
Suggestions
Expand the workflow slightly to mention how to interpret the output (e.g., 'Fix items marked ERROR first, then WARN') to improve workflow clarity.
Consider adding a brief example of what the output looks like (e.g., 'Score: 72/100, 3 errors, 5 warnings') so Claude knows what to expect and how to report results.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Very lean — every token earns its place. No unnecessary explanation of what React is or how npx works. The description and command are minimal and sufficient. | 3 / 3 |
Actionability | Provides a fully copy-paste ready command with specific flags (--verbose --diff). Claude can execute this immediately without any ambiguity. | 3 / 3 |
Workflow Clarity | The workflow mentions running, fixing errors, and re-running to verify improvement, which is a basic feedback loop. However, it lacks explicit validation checkpoints or guidance on what to do with specific error categories (errors vs warnings), and the sequence is vague ('fix errors first' without specifics). | 2 / 3 |
Progressive Disclosure | For a simple, single-purpose skill under 50 lines with no need for external references, the content is well-organized with clear sections (Usage, Workflow). No unnecessary nesting or missing structure. | 3 / 3 |
Total | 11 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- freekmurze/dotfiles
- Commit
2c6f6e8
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.