Audit Prompting Postures

Purpose

The official prompting guide prescribes posture guidance that agentic components should CARRY: delegation criteria, scope guardrails, grounding instructions, autonomy postures, confirmation gates. audit-instructions detects instruction text that is present and wrong; nothing detects text that is absent and needed. This skill is that additive lane: it classifies each component by purpose, checks the postures that purpose calls for, and proposes additions with wording taken from a live fetch of the guide, never from this file.

Read-only contract

Report-only. No --fix: every proposed addition is applied by the human (or explicitly delegated afterward). A clean audit is a valid outcome, and with well-authored components it is the expected one. The default verdict per posture is NOT-APPLICABLE, not MISSING.

Instruction-held, not tool-enforced. Never tell an operator this skill cannot edit their files. disallowed-tools: Edit, NotebookEdit narrows the surface, nothing more: Write stays for Phase D's persist and Phase B has already read every audited component, so it can overwrite one; Bash stays for the state key, and a shell mutates files too. That closes the likeliest accidental path, not the capability, and a skill auditing assurance must not overstate its own. (https://code.claude.com/docs/en/skills, fetched 2026-08-12; the restriction clears on the human's next message, so whoever accepts a proposal can apply it.)

Scope boundary (route out)

• Text that is present and wrong, covering over-prescription, stale claims, emphasis language and retired parameters, is audit-instructions. When one sweep wants both lanes, run both skills; a coordinated pass (audit-pass, when installed) composes them.
• Structural skill lint is skill-quality:check; token brevity is docs-hygiene:compress.
• Upstream-owned surfaces (installed plugin cache, managed materializations) produce routing recommendations to the owning repository, never in-place proposals, the same exclusion audit-instructions applies.

Phase A: Fetch the guide

The posture catalog in reference/postures.md carries, per posture, an applicability predicate and a POINTER to the guide section that states the recommended wording. It deliberately carries no copied sample text, so no proposal is written before the page it cites is in hand. It names two kinds of page; they are fetched at different times and fail differently.

The best-practices page: fetched here, every run, before any judging. It is this skill's one non-negotiable input: every posture points at it, so losing it degrades all ten at once. If it cannot be fetched, ABORT the run, naming the URL and the failure; continuing would emit ten wording-unverified postures, a report shaped like an audit that audited nothing. Same posture the sibling takes on its own single input (audit-instructions/SKILL.md, "Fail loud on ambiguity").

Model-specific subpages: fetched lazily, in Phase C, per applicable row, when a posture whose predicate actually matched points at one, not once per catalog row, since a row names its subpage statically whether or not anything in scope matches. A failed subpage fetch degrades only the postures citing it: mark those wording-unverified, carry the pointer instead of wording, never invent text. One page is fatal; the rest are local, and "before judging anything" is not a requirement to hold every page at once.

Phase B: Inventory and classify

Parse $ARGUMENTS for an optional scope filter (skills, agents, hooks, output-styles, claude-md, rules, or all, the default). It narrows which surfaces may produce findings, never which pages Phase A fetches.

Enumerate locally-owned instruction components in scope. This skill names its own surface set; what it shares with audit-instructions Phase A is the resolution procedure, not the list. Resolve ${CLAUDE_CONFIG_DIR:-~/.claude} and project .claude/, and apply the same liveness and upstream-ownership exclusions. The set, one entry per scope token above: skill bodies (and the context/reference files a skill instructs the model to read), agent definition markdown, hook instruction text of both kinds, output-style markdown, CLAUDE.md / CLAUDE.local.md, .claude/rules/. The inventory bounds what may produce a finding, not what counts as evidence. Phase C's mechanical-gate rule reads outside it to establish PRESENCE, which can only turn a MISSING into a PRESENT, never add a finding on an excluded surface.

For each component, classify its purpose from its own description and body. The classification vocabulary and its tie to each posture's predicate live in the catalog. A component can match several purposes or none; none is the common case, and unclassified components go in the coverage line rather than being force-fitted.

Phase C: Judge postures

For each component × applicable posture: does the component (or a file it instructs the model to read) already carry the posture, in any wording? Judge substance, not phrasing. A numeric concurrency cap satisfies the delegation-criteria posture without quoting the guide. Only a genuine absence on a component whose purpose clearly needs it becomes a finding. Three standing fences:

• Do not manufacture. The predicate must match the component's actual purpose, not a conceivable use. When in doubt, NOT-APPLICABLE.
• Mechanical gates are presence evidence and do not live in the inventory. P7, and only P7, blesses a deny-by-default hook or script gate "without any prose", while Phase B inventories instruction text, so those gates sit outside that set by construction. Before judging a destructive-capable component MISSING on P7, look in all three: settings scopes Phase B resolved (permissions.deny / ask), hook config registering a PreToolUse matcher over the action, and the script the component delegates the action to, following the invocation and reading it, since a component whose destructive step runs through a script that performs the approval check is gated. Any one of the three is PRESENT, cited by file and rule, or by script and line.
• Repo conventions win on wording. The proposal adapts the guide's substance to the component's own voice and the repo's terseness conventions; it never pastes a guide block verbatim into a proposal without trimming to what the component needs.

Phase D: Verify and report

Dispatch one fresh-context, non-fork verifier per surface batch, prompted to refute each proposed addition: "argue this component's purpose does not need this posture, or that it already carries it." A refuted finding is demoted to info and kept, never dropped. It stays a row carrying its refutation, because deleting it erases the evidence that Phase D ran and disagreed.

When dispatch is unavailable

Phase D requires fresh-context, non-fork verifier dispatch. When the Agent tool is blocked, unavailable, or the session cannot spawn subagents:

1. Disclose in the report header that Phase D did not run and why.
2. Mark unverified proposals. Every proposed addition that did not receive an independent verifier carries an (unverified) marker and is never presented as a confident finding.
3. Add a verifier attestation line to the report tail, naming components verified, verified inline, or skipped, alongside the existing coverage and Sources lines.

Persist the report to ${CLAUDE_PLUGIN_DATA}/audit-prompting-postures/<state-key>/last-audit.md.

Derive <state-key> by running this:

bash "${CLAUDE_PLUGIN_ROOT}/lib/state-key.sh"

${CLAUDE_PLUGIN_DATA} is machine-global, not per-project, so a fixed last-audit.md is silently overwritten by the next run from any other root, this skill's only durable deliverable, destroyed by ordinary use of it. The scheme is <repo-identity>/<worktree-discriminator>, defined by the marketplace's plugin-data-report-keying convention and reused rather than reinvented, and it lives in one executable rather than being restated per skill, lib/state-key.sh, with lib/state-key.test.sh beside it. Pass --explain when the report should say which rung produced the key. The key stops overwrites, not reaping. "By default, uninstalling from the last remaining scope also deletes the plugin's ${CLAUDE_PLUGIN_DATA} directory. Use --keep-data to preserve it." (https://code.claude.com/docs/en/plugins-reference, plugin uninstall, fetched 2026-08-12), so when a report must outlive the plugin the closing line says to copy it out of the data directory.

Run it and use the result. Do not express the path as a condition over ${CLAUDE_PROJECT_DIR} "when set": that placeholder is substituted inline before this file reaches you, so the literal token is never visible and the condition is not yours to evaluate. Derive the key from a command you run.

Open the report with a three-line header, so a file that does survive is self-describing rather than merely un-overwritten:

Resolved root: <absolute path audited>
Scope filter:  <the scope argument this run used, or "all">
Run (UTC):     <ISO-8601 timestamp>

Then summarize in chat:

Verdicts are a closed set of four tokens: MISSING (finding, with proposed addition as a fenced diff), PRESENT (where it is), NOT-APPLICABLE (with the failed predicate), info (a Phase D verifier refuted it, always kept as a row, never dropped, never a proposal to apply). Two markers are orthogonal and ride alongside a verdict, never in place of one: wording-unverified (a subpage fetch failed in Phase C, so the fifth column then carries the guide POINTER, which is what that column is named for, and a pointer is never dressed up as guide wording) and (unverified) (Phase D could not verify this proposal; see "When dispatch is unavailable"). End with a coverage line naming components inventoried, classified and unclassified, and a Sources line citing the pages fetched this run with dates. When Phase D ran, end with a verifier attestation line naming surface batches verified, verified inline, or skipped.

Gotchas

• Presence can live one file away. A SKILL.md that routes to a context file the model must read counts as carrying whatever that file carries. Follow the component's own read instructions before judging absence.
• Human-gated designs are not missing autonomy postures. A report-only skill that ends at a human gate needs no autonomous-pipeline branch; the autonomy posture applies to components that claim unattended operation.
• Model-conditional postures stay conditional. Where the guide ties a posture to specific models, the proposal must be model-neutral or carry the same condition, since components here run on any consumer model.

What this skill does NOT do

• Never edits a component and never auto-applies a proposal. This is held by instruction, since disallowed-tools narrows the surface but Write and Bash remain and both can mutate a file.
• Never copies guide text into its own catalog; wording comes from the run's live fetch.
• Does not judge existing text (that is audit-instructions), lint structure (skill-quality:check), or compress prose (docs-hygiene:compress).