agentsclimarketplace

Audit rule

Skill gnomatix/steering/.claude/skills/audit-rule

First-pass version of a cross-vendor "steering file" auditor / linter "suite"; immediately runnable via provided scripts using 'claude' CLI. #yourewelcome

Install
npx -y skills add gnomatix/steering --skill audit-rule

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Audit a behavioral RULE document — CLAUDE.md, steering file, system prompt directive, project convention, .cursorrules, .cursor/rules/*.mdc, .kiro/steering/*.md. Catches behavior-vs-surface failures, embedded biases, escape hatches, and other ways the rule can be technically followed while violating its intent. Use when reviewing or revising any document that prescribes always-on or auto-included agent behavior. SKIP for invocable skill files (use audit-skill) or multi-step workflow documents (use audit-workflow).

SKILL.md

4.0 KB, 793 tokens by cl100k_base, as published. Nobody here has run it

Audit Rule

Audit a behavioral RULE document. RULEs are always-loaded (or auto-included) prescriptions of agent behavior — distinct from SKILLs (invocable on-demand) and WORKFLOWs (multi-step procedures with checkpoints).

When to Use

  • Reviewing or revising a CLAUDE.md, steering file, system prompt, or behavioral spec
  • Drafting new agent rules or organizational standards
  • Diagnosing why a rule that appears clear is producing unwanted behavior
  • Before adopting a rule wholesale from another project or person

When NOT to Use

  • The document is an invocable skill with frontmatter trigger conditions → use audit-skill
  • The document is a multi-step procedure with phases and checkpoints → use audit-workflow
  • The document is one of many related documents and the cross-document structure is in scope → use audit-collection

Workflow

  1. Read the rule in full. Don't paraphrase. The exact wording is what's enforced.
  2. State the rule's intent in one sentence. If you can't, the rule has a clarity problem before any of the other checks apply.
  3. Identify the document type. Confirm it's a RULE (not a SKILL or WORKFLOW). See steering-audit-suite/shared/doc-types.md for discriminators.
  4. Read at least two structurally-proven exemplars of rules in the same vendor format. See steering-audit-suite/shared/reference-exemplars.md.
  5. Walk the audit checklist (15 checks) from steering-audit-suite/shared/checklist.md. For each, note specific evidence — line references, exact phrases. Mark "no finding" explicitly for each check applied.
  6. Distinguish surface fixes from intent fixes. Some findings are wording issues; some indicate the rule's intent is unclear or contested.
  7. Produce the audit report in the format defined in steering-audit-suite/shared/output-format.md.
  8. Do not rewrite without authorization. Present findings; let the author decide.

Skip the Portability Pass

RULEs prescribe behavior, not tools. Skip the portability/graceful-degradation audit (that's for SKILLs and tool-prescribing WORKFLOWs).

Reference Files

When in this repo, read the shared/ content for full details:

  • steering-audit-suite/shared/checklist.md — the 15 checks
  • steering-audit-suite/shared/doc-types.md — RULE vs SKILL vs WORKFLOW
  • steering-audit-suite/shared/reference-exemplars.md — finding exemplars per vendor
  • steering-audit-suite/shared/output-format.md — report shape

When installed standalone (copied out of the repo), the SKILL.md is the canonical reference. Inline the shared content if needed.

Anti-Patterns

  • Don't audit your own session behavior into the rule. If the rule applies to you and you've been violating it, the audit isn't the place to confess.
  • Don't gut the original wording in the audit output. Quote it; don't replace it.
  • Don't make stylistic preference findings. Audit for behavior leakage, not aesthetics.
  • Don't add new rules. The audit surfaces findings about the existing rule, not new rules to adopt.
  • Anti-patterns and the audit checklist are non-exhaustive — see steering-audit-suite/shared/checklist.md and use the "Other Findings" section of the report for issues outside the enumerated checks.

Resilience to Correction

If the document owner contests a finding, quote the finding back with the owner's response in the audit record. Do not silently drop a contested finding; do not double down without engaging with the owner's reasoning.

Gives 0 of the 12 instructions most audit compliance skills give in 793 tokens

Counted across 936 of the 1,487 authors here whose files we hold, read 2026-08-06

  • group findings by severityin 44 of 936
  • Fetch latest guidelines before each reviewin 43 of 936, across 3 files
  • Check files against all fetched rulesin 42 of 936, across 2 files
  • Output findings in terse file:line formatin 41 of 936, across 3 files
  • Ask user which files to review if none specifiedin 41 of 936, across 3 files
  • Read specified files or prompt user for filesin 39 of 936, across 1 file
  • generate the audit reportin 39 of 936, across 36 files
  • assign a severity to every findingin 25 of 936
  • run automated accessibility scansin 23 of 936, across 13 files
  • map findings to WCAG criteriain 20 of 936, across 10 files
  • confirm audit scopein 19 of 936, across 9 files
  • check title tags and meta descriptions for uniquenessin 19 of 936, across 5 files

Said here and by no other author read

  • read the rule in full without paraphrasing
  • state the rule's intent in one sentence
  • read at least two proven exemplars of the format
  • walk the 15-check audit checklist
  • mark no finding explicitly when applicable
  • distinguish surface fixes from intent fixes

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.