remove-mlinter-rule
Skill12 starsChanged 3 months agoApache-2.0View on GitHub
Retire a TRF rule from the mlinter. Marks the rule deprecated in rules.toml, deletes its module and tests, and records the removal in the CHANGELOG. Use when asked to remove, retire, drop, or delete a rule.
In this repository3 other files it gives its agents.
- .ai/AGENTS.mdAGENTS.md
- add-mlinter-ruleSkill
- releaseSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 2 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 34
Never reuse a retired number for a new rule: the tombstone stays forever, and add-mlinter-rule picks the next number after the highest …
- Very specific: line 41
If the id is already marked deprecated = true, stop and report that it is already retired.
- Distinctive: line 46
Keep the table in place at its original position — ordering in this file is by rule id.
- Very specific: line 47
Delete default_enabled, allowlist_models, cutoff_date, and the whole [rules.TRFXXX.explanation] table.
- Distinctive: line 59
Delete the rule module.
- Very specific: line 65
Delete the rule's own test file, tests/test_trfXXX.py.
- Very specific: line 66
Remove the id from the public-API tests: the assertEqual(public_api.TRFXXX, "TRFXXX") line and the assertIn("TRFXXX", public_api.__all__) …
- Very specific: line 71
No new test is needed for the removal itself: test_bundled_deprecated_rules_are_fully_retired loops over every tombstone in the bundled …
- Very specific: line 80
If the removed rule was mentioned in README.md, docs/index.md, or any other hand-written doc page, update those too.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Remove Mlinter Rule
Input
<rule id>: the rule to retire, e.g.TRF054. Accept a bare number (54) and normalise it toTRFXXX, zero-padded to three digits.- Optional: the reason for the removal. Ask for one if none is given — it becomes the CHANGELOG entry and the tombstone description, and it is the only record contributors will have of why the rule went away.
Why a tombstone and not a deletion
Rule ids are referenced from outside this repo: # trf-ignore: TRFXXX comments in the transformers
tree, CI configs, and copies of rules.toml passed via --rules-toml. So a removal keeps a tombstone
entry in rules.toml instead of deleting the table:
- The engine drops a deprecated id from
TRF_RULES,TRF_RULE_SPECS,TRF_RULE_CHECKS,DEFAULT_ENABLED_TRF_RULES, themlinter.TRFXXXpublic constants, and--list-rules. Projects that still suppress or configure the id are silently unaffected. - The docs site is the exception: it keeps publishing a page for the id, built from the tombstone and
listed under
Removed ruleson the rule index. A number that used to fire has to stay findable by whoever meets it in an old CI log. - Asking for it explicitly (
--enable-rules TRFXXX,--rule TRFXXX) fails with exit code 2. - A rules TOML that still lists the id as an active rule fails the whole run with exit code 2. The
bundled
rules.tomlis the authority here, so this holds for custom files too. - Leaving
trfXXX.pyon disk while the id is deprecated is also an error, which is what makes a half-finished removal impossible to ship.
Never reuse a retired number for a new rule: the tombstone stays forever, and add-mlinter-rule picks
the next number after the highest trf*.py.
Workflow
- Confirm the rule exists and read it.
grep -n "\[rules.TRFXXX\]" mlinter/rules.tomland read the whole table plusmlinter/trfXXX.py.- If the id is already marked
deprecated = true, stop and report that it is already retired. - Summarise for the user what the rule checks and any
allowlist_models/cutoff_dateit carries, so they can confirm this is the rule they mean before anything is deleted.
- Replace the TOML table with a tombstone in
mlinter/rules.toml.- Keep the table in place at its original position — ordering in this file is by rule id.
- Delete
default_enabled,allowlist_models,cutoff_date, and the whole[rules.TRFXXX.explanation]table. - Leave exactly:
[rules.TRFXXX] deprecated = true description = "Removed in <version>: <one-line reason>." <version>is the version under development inpyproject.toml. The description is published: it is the whole of the retired rule's docs page and its row in theRemoved rulestable, so write it for someone who just hit the id in a CI log, not as an internal note.
- Delete the rule module.
git rm mlinter/trfXXX.py - Delete the tests.
- Delete the rule's own test file,
tests/test_trfXXX.py. - Remove the id from the public-API tests: the
assertEqual(public_api.TRFXXX, "TRFXXX")line and theassertIn("TRFXXX", public_api.__all__)line. grep -rn "TRFXXX" tests/ mlinter/must come back empty except for the tombstone inrules.toml. Watch for helper fixtures or shared source strings that only that rule used, and for any other rule's test that happened to reference it.- No new test is needed for the removal itself:
test_bundled_deprecated_rules_are_fully_retiredloops over every tombstone in the bundledrules.tomland asserts the module and the public constant are gone, so it starts covering the new id automatically.
- Delete the rule's own test file,
- Update
CHANGELOG.md.- Under
## [Unreleased], in a### Removedsection (create it if absent), state the id, what it checked, and why it is gone. Add the migration note that projects need no change: mlinter ignores the id, existing# trf-ignore: TRFXXXcomments are harmless, but a rules TOML of their own must mark the ruledeprecated = trueor drop it. - If the removed rule was mentioned in
README.md,docs/index.md, or any other hand-written doc page, update those too.docs/rules/is generated and git-ignored — there is nothing to delete there.
- Under
- Verify.
make lint make test make typecheck python -m mlinter --list-rules | grep TRFXXX # must print nothing python -m mlinter --rule TRFXXX # must exit 2 and say the rule is deprecated python -m mlinter --enable-all-trf-rules # must not error on the missing modulemake docs-rulesif the docs toolchain is available, to confirm the generator emits aRemovedpage for the id and lists it underRemoved ruleson the index — not a live rule page, and not nothing at all.
- Report.
- The tombstone, the deleted files, the CHANGELOG entry, and what a consumer of mlinter has to do
(nothing, unless they ship their own
rules.toml).
- The tombstone, the deleted files, the CHANGELOG entry, and what a consumer of mlinter has to do
(nothing, unless they ship their own
Reference
- Rule metadata and tombstones:
mlinter/rules.toml - Deprecation handling:
_load_rule_specs,_build_rule_checks,_validate_rule_ids, andBUNDLED_DEPRECATED_TRF_RULESinmlinter/mlinter.py - Public API surface:
mlinter/__init__.py - Rule tests:
tests/test_trfXXX.py - General linter tests:
tests/test_mlinter.py(engine behaviour under "Deprecated rules") - The inverse skill:
.ai/skills/add-mlinter-rule/SKILL.md
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

