a-stated-rule-needs-annotated-exceptions
A design rule with legitimate exceptions survives only if every exception carries its reason at the call site and the rule itself is greppable — otherwise nothing distinguishes an exception from a violation and the rule silently rots. Covers where the rule statement goes, where the reasons go, scoping the audit to the code the rule actually governs, and the limits of a comment-based check. Use when a stated…
- installs 8w
- 0
- 30-day movement
- starts with the next reading
- Related entries
- 1
- Connections
- 0
A SKILL.md that prescribes how to keep a design rule enforceable when it has legitimate exceptions: every exception gets its reason annotated at the call site, and the rule statement itself is written so it can be grepped. It covers where the rule and reasons live, how to scope an audit to the code the rule governs, and the limits of comment-based checks.
Reach for it when a stated convention is drifting and reviewers can no longer tell deliberate exceptions from careless violations.
Use it to
- Audit a drifting convention for unannotated exceptions
- Write a rule statement that is greppable
- Annotate exception reasons at call sites
- Decide whether a rule is enforceable before adopting it
For Developers writing and enforcing coding conventions in a codebase
- Host repository
- maxrave-dev/kotlin-footguns
- Host stars
- 479