Audit Master

Comprehensive examination across multiple dimensions. Each dimension can be invoked independently or combined.

Table of Contents

• •Dimension Selection
• •Available Dimensions
• •Intensity Levels
• •Dimension 1: Code Quality
• •Dimension 2: Planning Alignment
• •Dimension 3: Security
• •Dimension 4: Competitive
• •Dimension 5: Test Coverage
• •Combined Audit Output
• •Complete Reference Index
• •Related Skills

Dimension Selection

If user specifies dimensions explicitly (e.g., "audit security", "audit plans", "audit tests"), run those dimensions only.

If user says "audit" without specifying dimensions, use AskUserQuestion to prompt:

Which audit dimensions would you like to run?

Options (multiSelect):
1. Code Quality - Architecture, design, efficiency, correctness (Recommended)
2. Planning Alignment - Strategy→Architecture→Plans→Implementation
3. Security - Dependencies, secrets, auth, OWASP Top 10
4. Competitive - Compare against alternatives in the market
5. Test Coverage - Test quality, gaps, coverage analysis

If user says "audit everything" or "comprehensive audit", run ALL dimensions.

Available Dimensions

Intensity Levels

All dimensions support three intensity levels:

Dimension 1: Code Quality

Comprehensive technical audit for architecture, design, efficiency, and correctness.

When to Use Code Quality

• •General health check
• •Before major work
• •Assessing technical debt
• •After significant changes

Code Quality Sub-Dimensions

Code Quality Process

See references/code-quality/ for detailed checklists covering:

1. •Scope identification (whole project or specific area)
2. •Sub-dimension selection (based on project type)
3. •Systematic execution of applicable checklists
4. •Evidence-based findings documentation

Code Quality Output

Code Quality Audit:
  Architecture: [rating] | Design: [rating] | Efficiency: [rating]
  Findings: P0: n | P1: n | P2: n | P3: n

Dimension 2: Planning Alignment

Hierarchical alignment audit across the planning stack:

Strategy/Vision → Architecture → Plans → Implementation

Each layer should logically derive from the one above. This dimension audits for alignment gaps, staleness, completeness, and coherence at each level.

When to Use Planning Alignment

• •Plans feel disconnected from reality
• •Before major planning sessions
• •After strategy changes to check downstream impact
• •Feeling "lost" about project direction

The Planning Stack

Layer 1: Strategy/Vision

Files: PROJECT_SPEC.md, VISION.md, STRATEGY.md, PROJECT.md

What this layer defines:

• •What are we building and why?
• •Who is it for?
• •What problems does it solve?
• •What is success?

Layer 2: Architecture

Files: ARCHITECTURE.md, system diagrams, ADRs (Architecture Decision Records)

What this layer defines:

• •How will we structure the solution?
• •What are the major components?
• •How do they interact?
• •What technologies/patterns?

Layer 3: Plans

Files: PLAN-*.md, BACKLOG-*.md, SPRINT-*.md, ROADMAP.md

What this layer defines:

• •What work needs to be done?
• •In what order?
• •What are the dependencies?

Layer 4: Implementation

Files: Actual code, EVALUATION-*.md, TODO-*.md

What this layer defines:

• •What has actually been built?
• •Does it match the plans?

Planning Horizon Guidelines

Anti-pattern: Detailed task breakdowns for work 3+ sprints out (waste, will change)

Anti-pattern: No visibility beyond current sprint (no strategic alignment)

Planning Process

See references/planning/ for detailed checklists at each intensity level:

• •Quick: quick-audit.md - Document location, spot-check alignment, flag obvious issues
• •Medium: medium-audit.md - Layer completeness, vertical traceability, horizontal consistency, staleness
• •Thorough: thorough-audit.md - Strategy coherence, architecture sufficiency, plan coverage/realism, implementation alignment

Planning Output

Planning Audit:
  Strategy:     [rating] [issues]
  Architecture: [rating] [issues]
  Plans:        [rating] [issues]
  Alignment:    [rating] [issues]

Critical Gaps: [n]
Stale Documents: [n]

Planning Ratings

Dimension 3: Security

Systematic security assessment of the codebase and dependencies.

When to Use Security

• •Before deployment to production
• •After adding auth/payment/sensitive data handling
• •Periodic security review
• •After dependency updates

Security Scope

Security Process

See references/security/ for detailed checklists covering:

• •Dependency audit (npm audit, pip-audit, govulncheck, cargo audit)
• •Secret detection (gitleaks, trufflehog)
• •Authentication review (auth-checklist.md)
• •Authorization review
• •Data exposure review
• •OWASP Top 10 review (owasp-checklist.md)
• •Input validation review

Security Intensity Levels

Security Output

Security Audit:
  Risk Level: [Critical/High/Medium/Low]
  CVEs: n critical, n high | Secrets: [status]
  OWASP: [summary]

Security Severity Definitions

Dimension 4: Competitive

Systematic comparison of this project against competitors and alternatives in the market.

When to Use Competitive

• •Before major feature planning (what should we build?)
• •When positioning the product
• •To identify gaps and opportunities
• •To validate differentiation claims

What Competitive Audit Does

1. •Identify competitors - Direct competitors, alternatives, adjacent solutions
2. •Analyze their approach - Features, architecture, UX, pricing
3. •Compare systematically - Feature-by-feature, capability-by-capability
4. •Find gaps - What do they have that we don't?
5. •Find opportunities - What could we do better? What's missing in market?
6. •Assess differentiation - Is our differentiation real and valuable?

Competitive Process

See references/competitive/research-template.md for the complete 6-step process:

1. •Understand our project
2. •Identify competitors (direct, indirect, adjacent, emerging)
3. •Research each competitor (features, approach, users, strengths, weaknesses)
4. •Feature comparison matrix
5. •Gap analysis
6. •Opportunity analysis

Use do:researcher with WebSearch for external research.

Competitive Intensity Levels

Competitive Output

Competitive Audit:
  Position: [assessment]
  Gaps: n | Opportunities: n
  Differentiators: n validated

Dimension 5: Test Coverage

Forensic analysis of test coverage quality. Not just "do you have tests" but "are you testing the right things at the right level?"

When to Use Test Coverage

• •Reviewing test quality
• •Identifying testing gaps
• •Auditing test strategy
• •Before planning test improvements

Testing Philosophy

The Testing Pyramid

         ╱╲
        ╱E2E╲          Few, slow, high-confidence
       ╱──────╲
      ╱ Integ  ╲       Medium count, medium speed
     ╱──────────╲
    ╱    Unit    ╲     Many, fast, focused
   ╱──────────────╲

Comprehensive Testing Level Definitions: references/testing/concepts/testing-levels.md

Testing at the Right Level

Wrong level → wasted effort, false confidence, or fragile tests

Common AI/LLM Testing Mistakes

When AI generates tests, it often makes systematic errors. Read: references/testing/concepts/llm-testing-mistakes.md

Test Coverage Process

See references/testing/ for comprehensive coverage audit process covering:

Phase 1: Complexity Source Detection

• •Architecture detection (microservices.md)
• •Data interaction detection (data-interactions.md)
• •External API detection (external-apis.md)
• •Interactive/user input detection (interactive-testing.md)

Phase 2: Project Type & Language Detection

• •Project type scenarios (15 types: CLI, web frontend/backend, mobile, etc. - see references/testing/scenarios/)
• •Language-specific testing (6 languages: Python, TypeScript, Go, Rust, Java, Ruby - see references/testing/languages/)

Phase 3-6: Inventory, Coverage Mapping, Quality Assessment, Gap Analysis

• •Test inventory and categorization
• •Coverage matrix creation
• •Red flag detection
• •Test quality checklist
• •Prioritized gap analysis (P0/P1/P2)

Test Coverage Intensity Levels

Test Coverage Output

Test Coverage Audit:
  Overall Health: [Healthy | Needs Work | Critical Gaps]
  Coverage Distribution: Unit n% | Integration n% | E2E n%
  Critical Gaps: [n] | Quality Issues: [n]

Combined Audit Output

When multiple dimensions run:

═══════════════════════════════════════
Audit Complete - [dimensions run]

Code Quality:
  Architecture: [rating] | Design: [rating] | Efficiency: [rating]
  Findings: P0: n | P1: n | P2: n | P3: n

Planning:
  Strategy: [rating] | Alignment: [rating]
  Gaps: n | Stale docs: n

Security:
  Risk Level: [Critical/High/Medium/Low]
  CVEs: n critical, n high | Secrets: [status]

Competitive:
  Position: [assessment]
  Gaps: n | Opportunities: n

Test Coverage:
  Health: [rating] | Gaps: n critical, n significant
  Distribution: Unit n% | Integration n% | E2E n%

Reports:
  - EVALUATION-<timestamp>.md
  - PLANNING-AUDIT-<timestamp>.md (if planning dimension)
  - SECURITY-AUDIT-<timestamp>.md (if security dimension)
  - COMPETITIVE-AUDIT-<timestamp>.md (if competitive dimension)
  - TEST-COVERAGE-AUDIT-<timestamp>.md (if test dimension)
═══════════════════════════════════════

Priority Levels

Capture Audit Findings

After generating the audit report, capture high-priority findings as deferred work to ensure they're tracked:

For P0 and P1 findings, capture each as a work item:

Skill("do:deferred-work-capture") with:
  title: "[Dimension] <finding summary>"
  description: |
    Audit finding from [dimension] audit.

    Finding: <full description>
    Location: <file/area affected>
    Impact: <what's at risk>
    Recommendation: <suggested fix>
  type: bug  # for security, or task for quality/planning
  priority: 0  # for P0, or 1 for P1
  source_context: "audit-master <dimension> audit"

For P2 findings (batch capture):

Skill("do:deferred-work-capture") with:
  title: "Tech debt batch: <dimension> audit findings"
  description: |
    Medium-priority findings from [dimension] audit.

    Findings:
    - <finding 1>
    - <finding 2>
    - <finding 3>

    See: <audit-report-file.md>
  type: chore
  priority: 2
  source_context: "audit-master <dimension> audit batch"

Why capture audit findings?

• •Ensures critical findings aren't just reported and forgotten
• •Creates actionable work items from audit results
• •Enables tracking and follow-up across sessions

Complete Reference Index

Code Quality References

Planning References

Security References

Competitive References

Testing References

Concepts

Detection

Languages

Scenarios

Related Skills