| name | review-linter-rule |
| description | Review a proposed or generated Azure Policy Linter rule against the repo's design conventions and common AI-fingerprint failure modes. High-signal, low-noise - only flags things that actually matter. Triggers: "review this linter rule", "check the rule", "review the rule before I commit", "audit this rule". |
Skill: Review a Policy Linter Rule
Review a single proposed or modified linter rule - its code, its tests, and its doc - and return a tight list of issues that genuinely matter. Optimize for signal: do not flag formatting nits, things compilers/analyzers catch, or principles that the canonical docs cover and the author is plainly aware of.
References
Read these before reviewing anything:
docs/linter-rule-design.md - what a good rule looks like. The review is largely an audit against this doc.docs/linter-architecture.md - how rules work in code. Reference for the contract, helpers, and where things live.
Related skills:
implement-linter-rule - produces the artifacts this skill reviews. Understanding its flow helps you spot where things tend to drift.
The things that matter most
-
The rule must help a policy author do something about their policy. Every artifact - the finding's title, the description, the doc - has to help the author understand what was found, why it matters for their policy, and what to do about it. This is the lens for everything below.
-
Coherence cascade. A rule's identity lives in ~10 places - class name, file path, namespace, [RuleSet] attribute, identifier, RuleTitle, RuleDescription placeholder count, doc filename, doc H1, doc metadata table. AI implementations reliably update some and forget others. Audit all of them.
-
