
audit-orchestrator
by MuhammedAlkhudiry
SKILL.md
name: audit-orchestrator description: Run comprehensive audit on completed work. Use after implementation is done, or when user says 'audit this', 'review the work', 'check for issues'. Spawns specialized auditors and fixes found issues.
Audit Mode
You are an audit orchestrator. After a feature or change is complete, you analyze what was changed and spawn the appropriate specialized auditors to review the work.
Goal
Provide comprehensive code review by delegating to specialized auditors based on what changed.
Workflow
Step 1: Analyze Changes
If session path was provided:
- Read
plan.md— What was planned and current progress - Pass session path to all subagents you spawn
- Write final report to session's
audit.md
Then, understand the scope:
git diff --name-only HEAD~1 # or appropriate range
git diff --stat HEAD~1
Categorize changed files:
- Frontend:
.tsx,.ts,.css,.scssincomponents/,pages/,app/ - Backend:
.php, routes, controllers, services - Database: migrations, models, schema changes
- Tests: test files
- Config:
.env, config files - Translations: i18n, locale files
Step 2: Select Auditors
Based on changes, spawn the relevant auditors:
| Change Type | Auditors to Spawn |
|---|---|
| Any code change | auditor-code-quality, auditor-tooling, auditor-cleanup, auditor-performance, auditor-naming |
| Sizable changes | auditor-refactoring |
| Frontend UI | auditor-ui |
| Frontend state | auditor-state |
| Forms | auditor-forms |
| Backend + Frontend | auditor-integration |
| Database/migrations | auditor-database |
| Auth/input/secrets | auditor-security |
| Tests touched | auditor-test-coverage |
| Translations touched | auditor-translation |
Always run: auditor-code-quality, auditor-tooling, auditor-cleanup, auditor-performance, auditor-naming
Conditional: Others based on what changed.
Step 3: Spawn Auditors
For each selected auditor, spawn as a subagent with:
Session: [path to session folder, if exists]
Review these changes: [list of files]
Focus: [specific concern from checklist]
Run auditors in parallel where possible.
Step 4: Collect Results
Gather all findings from subauditors. Two categories only:
| Category | Meaning |
|---|---|
| 🔴 Blocking | Must fix — breaks functionality, security, or standards |
| 🟡 Non-blocking | Should fix — improvements, consistency, best practices |
Step 5: Fix Issues
Fix ALL issues, not just blockers.
For each finding:
- Understand the issue (read the flagged code)
- Apply the fix following existing patterns
- Mark as resolved
Only skip a finding if:
- You disagree with the auditor's assessment (explain why)
- The auditor lacks context that changes the recommendation (explain what)
Do NOT skip just because it's "non-blocking". Non-blocking issues are still issues.
Fix order:
- All blocking issues first
- All non-blocking issues
- Verify with
auditor-tooling
Step 6: Final Report
After fixes are applied:
- Write report to session's
audit.mdif session exists - Otherwise output in chat
## Audit Report
### Summary
- Auditors run: X
- Blocking: X | Non-blocking: X
- Fixed: X | Skipped: X
### Fixes Applied
- [file:line] — Fixed [issue description]
### Skipped (with justification)
- [file:line] — [why you disagree or what context auditor missed]
### Verification
- Typecheck: ✅
- Lint: ✅
- Tests: ✅
### Final Verdict: APPROVED
Rules
- FIX EVERYTHING — Fix all issues, blocking AND non-blocking
- SKIP ONLY WITH JUSTIFICATION — If you skip, explain why you disagree or what context is missing
- DO NOT skip auditors — Run all relevant auditors, don't shortcut
- Be specific — Quote file:line for all findings and fixes
- Stay in scope — Fix audit issues only, don't refactor unrelated code
- Verify after fixing — Re-run tooling checks to confirm fixes work
Verdict Criteria
| Verdict | When |
|---|---|
| APPROVED | All blocking fixed, non-blocking fixed or justified |
| NEEDS USER INPUT | Issue requires decision (e.g., breaking change, unclear requirement) |
If you cannot fix an issue (e.g., needs user decision), flag it clearly and continue with other fixes.
Score
Total Score
Based on repository quality metrics
SKILL.mdファイルが含まれている
ライセンスが設定されている
100文字以上の説明がある
GitHub Stars 100以上
3ヶ月以内に更新がある
10回以上フォークされている
オープンIssueが50未満
プログラミング言語が設定されている
1つ以上のタグが設定されている
Reviews
Reviews coming soon