mcpField
R
rule-research

rule-research

github.com/millioncoDevelopment15.1k446 installsUpdated 2w ago
Repository

About rule-research

rule-research is a development skill for defining precise detector contracts before implementation. It examines evidence and edge cases so rule-writing can implement the intended behavior without guessing.

Key features

  1. 01Defines rule behavior and runtime rationale
  2. 02Examines nearby rules, tests, and utilities
  3. 03Separates valid patterns from reportable cases
  4. 04Specifies detector analysis scope
  5. 05Produces an implementation-ready contract

Use cases

  1. 01Specify a new lint rule before coding
  2. 02Resolve edge cases that affect detection
  3. 03Prepare a contract for rule-writing

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/millionco/react-doctor --skill rule-research

After installing, type/rule-researchin Claude Code to confirm it loaded.

Details

From the project README

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

  1. Define the rule in one sentence: This rule catches <pattern> that causes <problem>.

  2. Explain the runtime reason.

  3. Inspect nearby rules, tests, utilities, and the generated registry.

  4. Use truffler before proposing a new detector or helper:

    bunx @rayhanadev/truffler "<symbol-or-behavior>" \
  packages/oxlint-plugin-react-doctor/src/plugin \
  --kind function,interface,type,constant --limit 20

  5. Gather official documentation, implementation notes, related linter behavior, and open-source examples.

  6. Separate strong positives, adjacent patterns, valid traps, and unsupported cases.

  7. 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:

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.

Comments

Markdown supported