mcpField
R
rule-validate

rule-validate

github.com/millioncoTesting & quality15.1k462 installsUpdated 2w ago
Repository

About rule-validate

rule-validate is a development skill for maintainers checking rule implementations against their contracts. It guides code review, testing, release preparation, and evidence-based reporting of results or blockers.

Key features

  1. 01Review rule behavior and detection limits
  2. 02Add focused regression tests
  3. 03Run tests, typechecks, and lint
  4. 04Inspect RDE results and parity
  5. 05Prepare changesets and review notes
  6. 06Report validation evidence and open issues

Use cases

  1. 01Check a new rule against its research contract
  2. 02Fix false positives and add regression coverage
  3. 03Prepare release materials for a rule change

Install

Copy the command and run it in a terminal.

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

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

Details

From the project README

Validate a rule

Verify that the implementation matches its rule-research contract on tests and real code.

Review the implementation

Check for:

  • false positives and missed claimed behavior
  • incorrect imports, aliases, or shadowed bindings
  • impossible control-flow path merges
  • nested functions treated as immediate execution
  • dynamic properties treated as static names
  • missed transparent wrappers
  • unsupported imported values
  • messages that overstate detection
  • missing valid and invalid tests

Use truffler before accepting a new helper:

bunx @rayhanadev/truffler "<helper-name>" packages \
  --kind function,method,interface,type,constant --limit 20

Fix each implementation bug with a focused regression test.

Run validation

Run focused tests, package typecheck, and required lint and format checks. Run broader checks when the change affects shared behavior.

Use rde-eval for bounded local inspection of the target rule. Inspect all hits when counts are low and a representative sample when counts are high. Add every confirmed false positive to rule tests and the fuzz corpus.

Run run-parity for every new rule or detector behavior change after the pull request head is pushed. Skip it for documentation-only or test-only changes. If parity cannot run, report the exact blocker.

Do not claim parity unless both Vercel Sandbox runs complete. Compare repository and project-root counts separately. Inspect target-rule deltas before classifying them.

Prepare release artifacts

Run nr changeset for user-visible changes to published packages. Use a patch changeset for rules, bug fixes, false-positive fixes, and diagnostic refinements unless release impact requires more. Skip only private, documentation, test, or tooling changes, and state why.

Write pull request copy after validation:

## Why

<specific runtime problem>

## What changed

- <detector behavior>
- <valid patterns preserved>
- <tests added>

## Eval results

| Check             | Result                |
| ----------------- | --------------------- |
| Projects compared | `<count>`             |
| Skipped projects  | `<count>`             |
| Added / removed   | `<added> / <removed>` |
| Target rule delta | `<added> / <removed>` |
| False positives   | `<count>`             |
| Artifacts         | `<paths>`             |

## Test plan

- `<command and result>`

Omit the eval table when parity did not run. State the reason instead.

Handle review findings

Fix correctness bugs, duplicated helpers, misleading names, and confusing code. Defer unsupported control flow only when it falls outside the contract. Reject requests that broaden the message or increase false positives.

Resolve review threads after the fix or explanation reaches the pull request.

Report validation

Report commands, review findings, local RDE evidence, parity results or blocker, false positives fixed, regression tests, changeset, pull request notes, and residual non-goals.

Comments

Markdown supported