AgentSkillsCN

audit-orchestrator

对已完成的工作进行全面审计。仅在用户明确提出需求时启用——比如“对这项工作进行审计”“把工作再过一遍”“排查一下有没有问题”。切勿在项目上线后自动触发。系统会调派专业审计人员,针对发现的问题逐一整改。

SKILL.md
--- frontmatter
name: audit-orchestrator
description: Run comprehensive audit on completed work. Use ONLY when user explicitly asks - says 'audit this', 'review the work', 'check for issues'. Never trigger automatically after implementation. Spawns specialized auditors and fixes found issues.

Audit Mode

You are an audit orchestrator. 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:

  • Write final report to session's audit.md

Then, understand the scope:

bash
git diff --name-only HEAD~1  # or appropriate range
git diff --stat HEAD~1

Categorize changed files:

  • Frontend: .tsx, .ts, .css, .scss in components/, 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 TypeAuditors to Spawn
Frontend changesauditor-frontend-ui-ux
Backend changesauditor-backend
Backend + Frontendauditor-integration
Tests touchedauditor-test-coverage

Select auditors based on what files changed. Both auditor-backend and auditor-frontend-ui-ux include code quality checks.

Step 3: Spawn Auditors

For each selected auditor, spawn as a subagent with:

code
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:

CategoryMeaning
🔴 BlockingMust fix — breaks functionality, security, or standards
🟡 Non-blockingShould fix — improvements, consistency, best practices

Step 5: Fix Issues

Fix ALL issues, not just blockers.

For each finding:

  1. Understand the issue (read the flagged code)
  2. Apply the fix following existing patterns
  3. 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:

  1. All blocking issues first
  2. All non-blocking issues
  3. Verify with tooling checks (typecheck, lint, tests)

Step 6: Final Report

After fixes are applied:

  1. Write report to session's audit.md if session exists
  2. Otherwise output in chat
markdown
## 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
  • Audit scope only — Fix audit issues, don't refactor unrelated code
  • Verify after fixing — Re-run tooling checks to confirm fixes work

Verdict Criteria

VerdictWhen
APPROVEDAll blocking fixed, non-blocking fixed or justified
NEEDS USER INPUTIssue 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.