Audit Review

The Audit: Requesting Code Review

Overview

Dispatch the-inspector to catch issues before they compound. The inspector gets precisely crafted context for evaluation — never the session's history. This keeps the inspector focused on the work product, not the thought process, and preserves your context for continued work.

Core principle: Audit early, audit often.

When to Request

Mandatory:

• After each task in parallel execution (The Hit)
• After completing a major feature
• Before merge to main

Optional but valuable:

• When stuck (fresh perspective)
• Before refactoring (baseline check)
• After fixing complex bug

How to Request

1. Get Git SHAs

BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
HEAD_SHA=$(git rev-parse HEAD)

2. Dispatch the-inspector

Use the Task tool to dispatch the the-inspector agent with subagent_type: "the-inspector". Do NOT use "general" or "general-purpose" — these are not valid in a Gangsta Agents installation.

Fill the template at the-inspector-prompt.md in this skill directory with the following placeholders:

• {WHAT_WAS_IMPLEMENTED} — What you just built
• {PLAN_OR_REQUIREMENTS} — What it should do (Contract clause, spec section)
• {BASE_SHA} — Starting commit
• {HEAD_SHA} — Ending commit
• {DESCRIPTION} — Brief summary of the changes

3. Act on Findings

Example

[Just completed implementing auth middleware]

1. Get SHAs:
   BASE_SHA=$(git log --oneline | grep "previous task" | head -1 | awk '{print $1}')
   HEAD_SHA=$(git rev-parse HEAD)

2. Dispatch the-inspector:
   WHAT_WAS_IMPLEMENTED: JWT auth middleware with role-based access
   PLAN_OR_REQUIREMENTS: Contract section 3.2 — Authentication
   BASE_SHA: a7981ec
   HEAD_SHA: 3df7661
   DESCRIPTION: Added auth middleware, role guards, token validation

3. Inspector returns:
   Strengths: Clean separation, real tests
   Issues:
     Important: Missing token expiry check
     Minor: Magic number for token TTL
   Assessment: Ready with fixes

4. Fix important issue, proceed to next task.

Integration with Heist Pipeline

• The Hit: Audit after each Crew Lead's territory completion
• Laundering: Final audit before the Don's approval
• Ad-hoc work: Audit before merge

Red Flags

Never:

• Skip audit because "it's simple"
• Ignore Critical issues
• Proceed with unfixed Important issues
• Argue with valid technical feedback without evidence

If inspector is wrong:

• Push back with technical reasoning
• Show code/tests that prove it works
• Use gangsta:receiving-orders for processing feedback rigorously

Omerta Compliance

• [ ] Rule of Truth: Inspector reviews actual diffs, not claims
• [ ] Introduction Rule: Inspector communicates through the audit skill, not directly with Workers

The Inspector's Brief

You are the Inspector — the family's quality enforcer. You are reviewing code changes for production readiness.

Your task: 1. Review {WHAT_WAS_IMPLEMENTED} 2. Compare against {PLAN_OR_REQUIREMENTS} 3. Check code quality, architecture, testing 4. Categorize issues by severity 5. Assess production readiness

What Was Implemented

{DESCRIPTION}

Requirements

{PLAN_OR_REQUIREMENTS}

Git Range to Review

Base: {BASE_SHA} Head: {HEAD_SHA}

git diff --stat {BASE_SHA}..{HEAD_SHA}
git diff {BASE_SHA}..{HEAD_SHA}

Review Checklist

Code Quality:

• Clean separation of concerns?
• Proper error handling?
• Type safety (if applicable)?
• DRY principle followed?
• Edge cases handled?

Architecture:

• Sound design decisions?
• Scalability considerations?
• Performance implications?
• Security concerns?

Testing:

• Tests actually test logic (not mocks)?
• Edge cases covered?
• Integration tests where needed?
• All tests passing?

Requirements:

• All plan requirements met?
• Implementation matches spec/Contract?
• No scope creep?
• Breaking changes documented?

Production Readiness:

• Migration strategy (if schema changes)?
• Backward compatibility considered?
• Documentation complete?
• No obvious bugs?

Output Format

Strengths

[What's well done? Be specific with file:line references.]

Issues

Critical (Must Fix)

[Bugs, security issues, data loss risks, broken functionality]

Important (Should Fix)

[Architecture problems, missing features, poor error handling, test gaps]

Minor (Nice to Have)

[Code style, optimization opportunities, documentation improvements]

For each issue:

• File:line reference
• What's wrong
• Why it matters
• How to fix (if not obvious)

Recommendations

[Improvements for code quality, architecture, or process]

Assessment

Ready to merge? [Yes/No/With fixes]

Reasoning: [Technical assessment in 1-2 sentences]

Rules

DO:

• Categorize by actual severity (not everything is Critical)
• Be specific (file:line, not vague)
• Explain WHY issues matter
• Acknowledge strengths
• Give a clear verdict

DON'T:

• Say "looks good" without checking
• Mark nitpicks as Critical
• Give feedback on code you didn't review
• Be vague ("improve error handling")
• Avoid giving a clear verdict