Back to Details

rule-writing

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Write a rule

编写规则

Implement the 
rule-research
contract. If none exists, define a compact contract before editing.
实现
rule-research
契约。如果不存在该契约，请先定义一个简洁的契约再进行编辑。

Plan the detector

规划检测器

State the diagnostic condition, required syntax and bindings, unsupported cases, and adversarial tests. Keep this plan short when the user already requested implementation.
Before adding a helper, search for one to reuse:
sh
bunx @rayhanadev/truffler "<symbol-or-behavior>" \
  packages/oxlint-plugin-react-doctor/src/plugin \
  --kind function,interface,type,constant --limit 20
Read 
docs/HOW_TO_WRITE_A_RULE.md
, nearby rules, utilities, and tests.
说明诊断条件、所需语法和绑定、不支持的情况以及对抗性测试。当用户已要求实现时，请保持此规划简洁。
在添加新工具前，先搜索是否有可复用的工具：
sh
bunx @rayhanadev/truffler "<symbol-or-behavior>" \
  packages/oxlint-plugin-react-doctor/src/plugin \
  --kind function,interface,type,constant --limit 20
阅读
docs/HOW_TO_WRITE_A_RULE.md
、相近规则、工具和测试文档。

Implement and test

实现与测试

  1. Write detector pseudocode.
  2. Add adversarial valid and invalid tests.
  3. Implement only the contract's supported behavior.
  4. Reuse utilities before creating new ones.
  5. Update generated registration with repository commands.
  6. Run focused tests and package checks.
  7. Use 
    rde-eval
    when real-code feedback could expose noise.
  8. Hand the finished change to 
    rule-validate
    .
Account for:
  • import aliases and shadowed bindings
  • nested functions that do not execute immediately
  • transparent JavaScript and TypeScript wrappers
  • dynamic computed properties
  • imported or unresolved values
  • framework escape hatches
  • control-flow paths required by the diagnostic claim
  • regressions found by reviews or evals
Keep uncertain cases quiet. Match the message to the condition the detector proves.
  1. 编写检测器伪代码。
  2. 添加对抗性有效和无效测试用例。
  3. 仅实现契约支持的行为。
  4. 优先复用现有工具，再创建新工具。
  5. 使用仓库命令更新生成的注册信息。
  6. 运行聚焦测试和包检查。
  7. 当真实代码反馈可能产生干扰时，使用
    rde-eval
    。
  8. 将完成的修改提交给
    rule-validate
    。
需要考虑以下情况：
  • 导入别名和遮蔽绑定
  • 不会立即执行的嵌套函数
  • 透明的JavaScript和TypeScript包装器
  • 动态计算属性
  • 已导入或未解析的值
  • 框架逃生舱口
  • 诊断声明所需的控制流路径
  • 评审或评估中发现的回归问题
对不确定的情况保持静默。确保提示信息与检测器验证的条件匹配。

Run repository checks

运行仓库检查

Use 
@antfu/ni
commands:
sh
nr test
nr lint
nr typecheck
nr format
nr smoke:json-report
Use focused commands while iterating. Record each command that ran.
使用
@antfu/ni
命令：
sh
nr test
nr lint
nr typecheck
nr format
nr smoke:json-report
迭代过程中使用聚焦命令。记录每个运行的命令。

Report the implementation

报告实现情况

Report changed rules, tests, registration, reused or added utilities, reported behavior, intentional non-goals, and validation results. End with the 
rule-validate
handoff.
报告修改的规则、测试、注册信息、复用或新增的工具、已报告的行为、有意设定的非目标以及验证结果。最后提交给
rule-validate
进行验证。