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:shbunx @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:
mdRule 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.


