agentleFS
redhat-developerredhat-developer/rhdh-skills/skills/refinement/openspec-audit-change/SKILL.md

openspec-audit-change

Skill20 starsChanged 20 days agoApache-2.0View on GitHub

Adversarially audits an OpenSpec change's artifacts against each other — and lightly against the codebase and repository conventions — for cross-artifact consistency before implementation. Use for "audit this change" or "run the audit". This is pre-implementation artifact coherence; for post-implementation code-vs-artifact verification, use openspec-verify-change instead.

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 6 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Select the change: If not given, run openspec list --json, show active (non-archived) changes with schema, and let the user choose.

    line 21
  2. Very specific:

    Gather artifacts and convention docs: Run openspec status --change "<name>" --json and openspec instructions apply --change "<name>" --json.

    line 24
  3. Very specific:

    stop: Only a parseable {"findings": [...]} — including an empty array — may proceed to the fix loop.

    line 71
  4. Distinctive:

    Never hardcode product-specific banlists — categories D and H load constraints from project convention files and schema context.

    line 86
  5. Very specific:

    Generate the audit report: Write openspec/changes/<name>/audit.md (and show the same content in chat) using …

    line 99
  6. Distinctive:

    Never skip the independent auditor subagent for a full audit.

    line 116
  7. Distinctive:

    Never invent product-specific rules in this skill's own body — load them from project files.

    line 119
  8. Distinctive:

    Never pivot into design-decision grilling for unresolved findings — report them only.

    line 121
  9. Distinctive:

    Never apply autofixes without explicit confirmation.

    line 123
  10. Distinctive:

    Always run the apply-ready minimum check before the ownership map or subagent — an incomplete change is CRITICAL and stops the audit early.

    line 125

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Audit an OpenSpec change

Spawn an isolated auditor over one change's artifacts, catch cross-artifact drift before code gets written, and never claim a clean audit the checks did not actually confirm.

Steps

  1. Select the change. If not given, run openspec list --json, show active (non-archived) changes with schema, and let the user choose. Never guess.
  2. Gather artifacts and convention docs. Run openspec status --change "<name>" --json and openspec instructions apply --change "<name>" --json; collect every artifact path from contextFiles plus .openspec.yaml. If the CLI is unavailable, fall back to filesystem discovery under openspec/changes/<name>/. Locate repo-root convention docs (AGENTS.md, CLAUDE.md, CONTRIBUTING.md) and the schema's context/rules if available from /rhdh-spec-driven-schema.
  3. Enforce the apply-ready minimum before doing anything else. Build the union of the schema's apply.requires (or CLI applyRequires) and {proposal, design, specs, tasks}. Preferred: every ID in that union must show status: "done" in the status JSON. Filesystem fallback: read .openspec.yaml for the schema name, read that schema's apply.requires, and check each mapped path exists and is non-empty (proposal->proposal.md, design->design.md, tasks->tasks.md, specs->at least one specs/**/spec.md). If the required set cannot be determined, or any required artifact is missing/not done: report CRITICAL, state "Audit blocked (CRITICAL findings remain)", write/update audit.md with the current UTC timestamp, suggest /openspec-continue-change, and stop — do not build the ownership map or spawn the auditor.
  4. Build a cross-change ownership map. Resolve sibling changes (reuse openspec list --json from step 1, or filesystem-list openspec/changes/* excluding this change and archive/). For each sibling, read only its proposal.md Canonical Touchpoints section and design.md Decisions section, and build a lightweight capability/namespace/claim -> [change names] map. Pass the map (or condensed claim lines), not full sibling trees, to the auditor. If sibling discovery fails entirely, pass an empty map and note category E ran degraded in the final report — do not fail the whole audit for this alone.
  5. Spawn an independent auditor subagent (Task tool, subagent_type: general-purpose). Give it only: change name, absolute artifact paths, the ownership map, convention doc paths, the checklist below, and the required JSON return schema. Explicitly forbid passing authoring rationale or "what we meant" — this is prompt isolation, not a sandbox; instruct it to limit reads to the given paths. Require it to return:

    {"findings": [{"category": "A|B|C|D|E|F|G|H", "severity": "CRITICAL|WARNING|SUGGESTION", "file": "openspec/changes/<name>/design.md", "line": 1, "quote": "short excerpt", "recommendation": "actionable fix", "autofixable": true}]}

    file must be repo-root-relative; normalize any absolute paths before writing audit.md. Fail-closed: if the subagent fails, times out, or returns malformed findings, treat it as CRITICAL — write/update audit.md with that CRITICAL and the current UTC timestamp, state "Audit blocked (CRITICAL findings remain)", report the failure, suggest retrying, and stop. Only a parseable {"findings": [...]} — including an empty array — may proceed to the fix loop.

  6. Auditor checklist (all categories evaluated):

    IDCategoryCatchesAutofixable
    AEntity propagationName/value fixed in design.md (or proposal.md) not identically propagated to sibling artifactsYes, if one unambiguous spelling
    BEnum / vocabularyEnumerated sets with different membership/count across files or vs openspec/specs/<capability>/Yes, if superset unambiguous
    CSemantic contradictionDesign fails to satisfy spec WHEN/THEN; Non-Goals vs Decisions; non-deterministic outcomes; Verify scoped differently than the taskNo
    DCodebase & convention groundingReferences to APIs/tickets/modules that don't exist; mechanisms violating loaded house rulesNo
    ENamespace & cross-change ownershipUnresolved openspec/changes/<id>/ refs; claim shared with a sibling with no reconciliation noteNo
    FTemplate/copy-paste residueLiteral paths/prefixes from a different project than this repoYes, if correct target unambiguous
    GExtended coherenceHelper signature vs call sites; shared exports not tasked into consumers; lifecycle semantics missing/inconsistent across artifactsYes when a name/signature is already fixed and merely missing in siblings; no for any WHEN/THEN or product-policy choice
    HSecurity lintMutating/admin routes with no authorize story; ambiguous DENY outcomes; hidden-count exposure; secrets in examplesOnly if design already named the permission and wiring is obvious

    Never hardcode product-specific banlists — categories D and H load constraints from project convention files and schema context. When uncertain, prefer SUGGESTION over WARNING, WARNING over CRITICAL.

  7. Fix-and-reaudit loop, up to 3 passes. Collect autofixable findings with one unambiguous canonical value (prefer the value in design.md Decisions; else the most frequent spelling agreeing with the proposal's Capabilities names). If none, stop the loop. Otherwise list the proposed mechanical fixes and ask the user: apply this batch, or skip autofix (report-only for remaining passes). On confirm, apply edits and re-spawn the auditor (same isolation and fail-closed rules); on skip, break and proceed to reporting with current findings. Never auto-apply non-autofixable (judgment-call) findings, and never apply any fix without explicit confirmation.
  8. Generate the audit report. Write openspec/changes/<name>/audit.md (and show the same content in chat) using references/audit-report-template.md, keeping its section structure. Always set Last audited to the current UTC time when writing. Every finding needs a repo-root-relative file reference and an actionable recommendation. A severity section with no findings must contain exactly - None.
  9. Report the outcome. Any CRITICAL remaining: state "Audit blocked (CRITICAL findings remain)" and list blockers — never claim a clean audit. No CRITICAL: state "Audit clean (no CRITICAL)" (WARNINGs may still be listed) — never say "Ready for implementation." Always close with: "Fixes to one file can introduce new drift elsewhere — re-run the audit after resolving remaining findings." This is advisory output; it does not gate /openspec-apply-change or /openspec-archive-change.

Guardrails

  • Never skip the independent auditor subagent for a full audit.
  • Fail-closed on subagent failure — never claim a clean audit from a failed or malformed response.
  • Never invent product-specific rules in this skill's own body — load them from project files.
  • Never pivot into design-decision grilling for unresolved findings — report them only.
  • Never apply autofixes without explicit confirmation; cap confirmed autofix loops at 3 passes.
  • Always run the apply-ready minimum check before the ownership map or subagent — an incomplete change is CRITICAL and stops the audit early.

Completion

Complete when audit.md reflects the latest auditor pass (or the latest CRITICAL blocker) with a current UTC timestamp, every finding carries a repo-root-relative file reference and recommendation, and the user has been told explicitly whether the audit is blocked or clean — never left to infer it.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.