How to not go overboard with rules and when to use skill instead?

when building a library for contribution, rules have been helpful for enforcing guidelines and patterns, but i feel like everything now is just becoming a rule by default. but writing rules to enforce API design and standard patterns and "how/what test coverage matters" feels overboard and feels wrong. as i understand it, rules sound more like more concrete smaller enforceable global constraints. what im mixing is that in my brain im thinking "i want to enforce all these API standards/patterns/testing rules/etc that normally our team is doing via review and knowledge share". therefore i naturally grab for building it as a rule to "enforce" it. my review skill also is simply "review each rule for the diff and ensure it's applied correctly". which again, feels wrong and wont scale. sure now it works, but what happens when my rules scale to dozens and dozens of very niche specific API patterns and standards. is that going to work? I want the ergonomics of "enforcement" and "guardrails" but the back of my head says this is wrong

添加评论
点赞收藏
点踩分享查看原文
评论
?
参与讨论