guardrail_audit

guardrail_audit

<guardrail_audit_skill>

<when_to_activate> Activate when the user wants the repo's existing guardrail docs audited:

• "Audit the guardrails" / "do the guardrail docs still match the code?" / "health-check CHARTER.md against the repo."
• "Retrofit a charter into this mature repo, so what already diverges?"
• "Are ARCHITECTURE.md / TESTING.md / SECURITY.md consistent with each other and with CLAUDE.md?"

Route to the guardrail hub when the user wants the system explained, a suggestion of which docs to adopt, or a draft of a new doc. Route to the task family for backlog work. </when_to_activate>

<audit_bound> Keep gap detection and missing-doc proposals to obvious, high-confidence cases. Exhaustive coverage analysis stays outside this skill's job: chasing every possible claim, every possible absent doc, and every speculative mismatch. Prefer a short ranked list of clear findings over a long list of thin ones. </audit_bound>

<normative_reading> Read every statement that carries guarding force as a guarding statement, including a mixed sentence that both guards and describes. Apply the hub's <role> and <format_contract> normative obligations whenever guarding force is present. Report code short of a rule as unmet work, name the code as the side to move, and propose no softening of the rule. Read a target in ARCHITECTURE.md's ## Direction in the declared-direction register the hub defines (its <hierarchy> spectrum, its <format_contract>, and its <consumption> "Steer work toward the declared direction" behaviour): a target the code has not reached is drive-toward work, reported by naming how the code moves toward the target or how the target is revised deliberately, and softening or deleting the target to match today's code is not among the directions offered. Keep the neutral both-directions presentation only for purely descriptive statements, present-tense description of what stands, where bringing the doc back to the repository is a legitimate fix per the hub's <consumption> "Surface, never auto-resolve" behaviour. </normative_reading>

1. Orient. Run the hub's <orient> first: resolve the project root, read the repository's nature, and inventory which guardrail docs, peers, and harness rule files are present. Presence-gate every doc read per the hub's <consumption>: audit exactly the docs that exist, and raise no missing-doc error for an absent type.
2. Doc-vs-doc. Compare the present docs across all three tiers the hub's <hierarchy> defines, harness rule files included, for contradictions and obvious gaps. Name the higher-tier doc as authoritative and flag the subordinate passage as the one to reconcile.
3. Doc-vs-code. Compare the present docs against the established codebase. Drive the scan from the falsifiable claims, taking the charter's DOES NOT boundaries and Key Invariants first, then the tier-2 docs' concrete assertions, so the assessment stays tractable on a large repo. Apply <normative_reading>: for a guarding statement, report unmet work with the code named as the side to move and offer no softening of the rule; for a declared direction target the code has not reached, report drive-toward work naming how the code moves toward the target or how the target is revised deliberately, and offer no softening or deletion of the target; for a purely descriptive statement, present-tense description of what stands, offer both reconcile directions (bring the doc back to the code, or evolve the code toward the doc).
4. Format and coverage findings. Within the <audit_bound>, also surface the three finding classes in <finding_classes> when the evidence is obvious and high-confidence.
5. Missing-doc proposals. Where repo substance plainly warrants an absent doc, apply the hub's <suggest> flow with the audit's evidence: describe what the doc would capture, name nature mismatches instead of proposing an ill-fitting type, and create nothing.
6. Report and ask. Emit the ranked findings per <output_contract>, leave every audited file byte-for-byte unchanged, and ask the user how to proceed.