How to use
- Copy the installation command and review the source package before installing it in your own agent environment.
- Check the source document for required tools, credentials and supported hosts.
- Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/millionco/react-doctor --skill rule-researchBefore you start
- Installation does not include a model subscription, API allowance or permission to access your files.
- Repository stars and installation counts describe activity, not an independent quality or security test.
Original skill document
Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
Research a rule
Produce a rule contract that rule-writing can implement without guessing.
Define the behavior
Resolve only questions that affect correctness:
- Which code pattern should report?
- Which runtime behavior makes it harmful?
- Which similar code must stay quiet?
- Does detection need syntax, scope, or path analysis?
- Which imported, dynamic, type-driven, or interprocedural cases stay out of scope?
If the user requested implementation, make the contract concise and continue.
Collect evidence
- Define the rule in one sentence:
This rule catches <pattern> that causes <problem>. - Explain the runtime reason.
- Inspect nearby rules, tests, utilities, and the generated registry.
- Use
trufflerbefore proposing a new detector or helper:
sh
bunx @rayhanadev/truffler "<symbol-or-behavior>" \
packages/oxlint-plugin-react-doctor/src/plugin \
--kind function,interface,type,constant --limit 20- Gather official documentation, implementation notes, related linter behavior, and open-source examples.
- Separate strong positives, adjacent patterns, valid traps, and unsupported cases.
- Choose syntax-only, scope-aware, or path-aware detection.
Use rde-eval when a bounded open-source sample could change the contract. Leave final pull request parity to rule-validate.
Write the contract
Return:
md
Rule definition:
<pattern and specific problem>
Runtime reason:
<short explanation>
Detector precision:
<syntax-only, scope-aware, or path-aware>
Evidence:
- <source and implication>
Strong positives:
- <reportable examples>
False-positive traps:
- <valid examples>
In scope:
- <supported cases>
Out of scope:
- <explicit boundaries>
Test seeds:
- <invalid and valid fixtures>
Open questions:
- <correctness blockers only>Treat false positives as correctness bugs. Keep the diagnostic narrower than or equal to the proven behavior. Split adjacent ideas into separate rules.
