Quality Audit Workflow

Purpose

When I Activate

• "quality audit" or "code audit"
• "codebase review" or "full code review"
• "refactoring opportunities" or "technical debt audit"
• "module quality check" or "architecture review"
• "parallel analysis" with multiple agents

What I Do

1. Familiarizes with the project (investigation phase)
2. Audits using parallel agents across codebase divisions
3. Creates GitHub issues for each discovered problem 3.5. Validates against recent PRs (prevents false positives)
4. Generates PRs in parallel worktrees per remaining issues
5. Reviews PRs with PM architect for prioritization
6. Reports consolidated recommendations in master issue

Quick Start

User: "Run a quality audit on this codebase"
Skill: *activates automatically*
       "Beginning quality audit workflow..."

The 7 Phases

Phase 1: Project Familiarization

• Run investigation workflow on project structure
• Map modules, dependencies, and entry points
• Understand existing patterns and architecture

Phase 2: Parallel Quality Audit

• Divide codebase into logical sections
• Deploy multiple agent types per section (analyzer, reviewer, security, optimizer)
• Apply PHILOSOPHY.md standards ruthlessly
• Check module size, complexity, single responsibility

Phase 3: Issue Assembly

• Create GitHub issue for each finding
• Include severity, location, recommendation
• Tag with appropriate labels
• Add unique IDs, keywords, and file metadata

Phase 3.5: Post-Audit Validation [NEW]

• Scan merged PRs from last 30 days (configurable)
• Calculate confidence scores for PR-issue matches
• Auto-close high-confidence matches (≥90%)
• Tag medium-confidence matches (70-89%) for verification
• Add bidirectional cross-references between issues and PRs
• Target: <5% false positive rate

Phase 4: Parallel PR Generation

• Create worktree per remaining open issue (

  worktrees/fix-issue-XXX

  )
• Run DEFAULT_WORKFLOW.md in each worktree
• Generate fix PR for each confirmed open issue

Phase 5: PM Review

• Invoke pm-architect skill
• Group PRs by category and priority
• Identify dependencies between fixes

Phase 6: Master Report

• Create master GitHub issue
• Link all related issues and PRs
• Prioritized action plan with recommendations

Philosophy Enforcement

• Ruthless Simplicity: Flag over-engineered modules
• Module Size Limits: Target <300 LOC per module
• Single Responsibility: One purpose per brick
• Zero-BS: No stubs, no TODOs, no dead code

Navigation Guide

When to Read Supporting Files

• Detailed phase execution steps
• Agent-to-phase mappings
• Codebase division strategies
• Issue template formats

• Working audit examples
• Sample issue/PR formats
• Real-world usage patterns
• Output format examples

Configuration

• AUDIT_PARALLEL_LIMIT

  : Max concurrent worktrees (default: 8)

• AUDIT_SEVERITY_THRESHOLD

  : Minimum severity to create issue (default: medium)

• AUDIT_MODULE_LOC_LIMIT

  : Flag modules exceeding this LOC (default: 300)

• AUDIT_PR_SCAN_DAYS

  : Days to scan for recent PRs (default: 30)

• AUDIT_AUTO_CLOSE_THRESHOLD

  : Confidence % for auto-close (default: 90)

• AUDIT_TAG_THRESHOLD

  : Confidence % for tagging (default: 70)

• AUDIT_ENABLE_VALIDATION

  : Enable Phase 3.5 (default: true)