enact-audit

Verifies completed projects against design documents via blind review, QA, and remediation subagents.

1|Updated Dec 18, 2009
One-click install
npx skills add https://github.com/thurn/dotfiles --skill enact-audit-thurn
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: enact-audit
Source: https://github.com/thurn/dotfiles/tree/main/.llms/skills/enact-audit
Command: npx skills add https://github.com/thurn/dotfiles --skill enact-audit-thurn

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Completed projects often drift from their design documents, and self-review by the same process that built the code introduces bias. This Skill performs an independent blind audit of a finished project against its spec, combining parallel code review, mandatory manual QA, and automatic bug remediation through coordinated subagents. ## Core Features & Use Cases - Blind Verification: Subagents review only the source tree and design document, explicitly forbidden from reading prior build plans, PR descriptions, or implementation notes, ensuring an unbiased conformance check. - Mandatory Manual QA with Fixture Building: If no test harness exists, the audit designs and builds debug endpoints, headless modes, seed fixtures, and scriptable shells rather than falling back to code-review-only. - Fix-and-Verify Remediation Loop: Every bug found goes through a Fixer then Verifier cycle (capped at 3 rounds before escalation), ending with a cross-feature review and a final REPORT.md. - Use Case: After an autonomous build pipeline finishes a web app, invoke /enact-audit with the repo path and design doc to get an independently verified, remediated worktree plus a report of fixes applied and spec ambiguities surfaced. ## Quick Start Run /enact-audit with the path to my completed project and the design document to independently verify the implementation, fix any bugs found, and produce a final audit report.

Frequently Asked Questions about enact-audit

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify a completed project against its design document?▼

Invoke /enact-audit with the project path and design document. The orchestrator writes an audit plan, decomposes the spec into checkable features, runs parallel code reviewers and QA scenarios per feature batch, then fixes and re-verifies every bug found.

What is a blind code review and why does it matter?▼

A blind review means auditors read only the source tree and spec, never prior build plans, PR descriptions, or implementation notes. This prevents bias from knowing how the code was built, so verification judges the implementation purely against what the spec requires.

Can an audit run if the project has no test harness or QA path?▼

Yes. The QA Strategist designs test surfaces such as debug endpoints, headless modes, seed fixtures, and scriptable shells, and the Fixture Builder implements them. Falling back to code-review-only is explicitly forbidden unless the enabling work is genuinely impossible.

What happens when the audit finds bugs in the implementation?▼

Each bug is filed with severity and reproduction steps, then a Fixer applies a reproduce-first fix and a Verifier re-runs the original failing checks. After three failed fix-verify rounds the bug is escalated and surfaced in the final report.

How are spec ambiguities handled during verification?▼

When the design document supports multiple reasonable interpretations, the auditor records the quoted passage, possible interpretations, the implementation's actual behavior, and a recommended default in an ambiguity file. These are surfaced to the user in the final report with a concrete question.