Claude Skill

audit

Project health audit and health check — architecture, performance, tests, dependencies, code quality. Use when assessing overall project health, before releases, or after refactors.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download oliver-kriska-claude-elixir-phoenix-plugins_elixir-phoenix_skills_audit-9767a82.zip · 7 KB
Part of oliver-kriska/claude-elixir-phoenix — 93 skills

Install

skills CLI npx skills add https://github.com/oliver-kriska/claude-elixir-phoenix/tree/main/plugins/elixir-phoenix/skills/audit
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install oliver-kriska-claude-elixir-phoenix@llmmart
Git git clone https://github.com/oliver-kriska/claude-elixir-phoenix.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole oliver-kriska/claude-elixir-phoenix collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Project Health Audit

Comprehensive project-wide health assessment using 5 parallel specialist subagents.

Usage

/phx:audit              # Full audit (default)
/phx:audit --quick      # 2-3 minute pulse check
/phx:audit --focus=security   # Deep dive single area
/phx:audit --focus=performance
/phx:audit --since abc123   # Incremental audit since commit
/phx:audit --since HEAD~10  # Audit last 10 commits

When to Use

  • Quarterly health checks
  • Before major releases
  • After large refactors
  • New team member onboarding (understand codebase health)

Iron Laws

  1. Wait for ALL agents before synthesizing — Partial results create misleading health scores because cross-category correlations get missed
  2. Scope agent prompts to specific directories — Vague prompts like "analyze the codebase" produce generic findings that waste tokens and miss real issues
  3. Never compare scores across projects — Scoring methodology depends on project size and maturity; only track trends within the same project
  4. Quick mode before full mode — Run --quick first to catch compile/test failures before spending tokens on 5 parallel agents

Subagent Architecture

Spawn 5 specialists in parallel using Agent tool. Three route to plugin specialists with a declared model; the two categories without a specialist use general-purpose pinned to model: "sonnet" — unpinned, they inherit the session model (Opus by default):

Subagent Focus Output File Routes to
Architecture Reviewer Structure quality, coupling, cohesion arch-review.md phoenix-patterns-analyst (sonnet)
Performance Auditor N+1, indexes, bottlenecks, scalability perf-audit.md general-purpose, model: "sonnet" (no perf specialist yet)
Security Auditor OWASP scan, auth patterns, secrets security-audit.md security-analyzer (opus)
Test Health Auditor Coverage, quality, flaky tests test-audit.md testing-reviewer (sonnet)
Dependency Auditor Vulnerabilities, outdated, unused deps-audit.md general-purpose, model: "sonnet" (hex-deps-triager is per-package only)

Workflow

Step 1: Create Task List and Spawn All 5 Auditors (Parallel)

If TaskCreate is in your tool list, create Claude Code tasks for progress visibility (Sonnet 5+ and Opus 4.8+ omit it unless CLAUDE_CODE_ENABLE_TODO_TOOLS=1; never ToolSearch for it — skip this block):

For each auditor:
  TaskCreate({subject: "{Area} audit", activeForm: "Auditing {area}..."})
  TaskUpdate({taskId, status: "in_progress"})

Then spawn all 5 agents with Agent tool (parallel). Route to declared-model specialists where they exist, keep general-purpose only where no specialist covers the audit category:

Agent(subagent_type: "phx:phoenix-patterns-analyst", prompt: "Architecture audit: analyze module structure, context boundaries, coupling, cohesion. Write findings to .claude/audit/reports/arch-review.md", run_in_background: true)
Agent(subagent_type: "general-purpose", model: "sonnet", prompt: "Performance audit: N+1 queries, missing indexes, bottlenecks, scalability. Write findings to .claude/audit/reports/perf-audit.md", run_in_background: true)
Agent(subagent_type: "phx:security-analyzer",        prompt: "Security audit: OWASP scan, auth patterns, secret leakage. Write findings to .claude/audit/reports/security-audit.md", run_in_background: true)
Agent(subagent_type: "phx:testing-reviewer",         prompt: "Test health audit: coverage, quality, flakes. Write findings to .claude/audit/reports/test-audit.md", run_in_background: true)
Agent(subagent_type: "general-purpose", model: "sonnet", prompt: "Dependency audit: vulnerabilities, outdated, unused. Write findings to .claude/audit/reports/deps-audit.md", run_in_background: true)

Why specialist routing matters: a general-purpose subagent without model: inherits the session model — Opus on every plan since CC 2.1.280. Plugin specialists declare their own model in frontmatter, and the two general-purpose tracks pin model: "sonnet", so no audit track runs on Opus.

Agent prompts must be FOCUSED. Scope each prompt to the relevant directories and patterns. Do NOT give vague prompts like "analyze the codebase."

Output efficiency: Tell each agent: "Report ONLY issues found. Do NOT list clean checks, passing categories, or 'What's Good'. One summary line per clean area suffices."

Step 2: Collect Results

Wait for ALL auditors to complete — one completion notification per agent spawned. If you created tasks, mark each completed as it finishes. NEVER proceed while any auditor is still running.

Read reports from .claude/audit/reports/.

Rate-limit circuit breaker: if 2+ auditors return empty results or rate-limit/API errors, STOP spawning. Synthesize from the reports that exist, mark missing categories as "not audited (rate limit)", and tell the user to re-run /phx:audit after the limit resets. Never leave the user typing "continue" against dead agents.

Step 3: Compress Findings

After all 5 auditors complete, spawn context-supervisor:

Agent(subagent_type: "phx:context-supervisor", prompt: """
Compress audit findings.
Input: .claude/audit/reports/
Output: .claude/audit/summaries/
Priority: Health scores per category, critical findings
only, cross-category correlations, deduplicate findings
found by 2+ agents.
""")

Read .claude/audit/summaries/consolidated.md for synthesis.

Step 4: Calculate Health Score

Each category scores 0-100. See ${CLAUDE_SKILL_DIR}/references/scoring-methodology.md.

Step 5: Generate Report

Write to .claude/audit/summaries/project-health-{date}.md.

Output Format

Report includes: Executive summary with health score (A-F, numeric/100), per-category score table (Architecture, Performance, Security, Tests, Dependencies), critical issues, top recommendations, and action plan (Immediate/Short-term/Long-term).

Quick Mode (--quick)

Only run essential checks (~2-3 minutes):

Run mix compile --warnings-as-errors, then mix hex.audit && mix deps.audit, then mix xref graph --format stats, then mix test --trace 2>&1 | tail -20.

Skip: Full security scan, N+1 analysis, test quality metrics, architecture deep dive.

Focus Mode (--focus=area)

Deep dive single area with full specialist resources:

Focus Subagent Extra Checks
security security-analyzer Full OWASP, sobelow, manual patterns
performance general-purpose Profile-level analysis, query explain (no plugin specialist yet)
architecture phoenix-patterns-analyst Full xref, coupling matrix, cohesion
tests testing-reviewer Coverage by context, quality metrics
deps general-purpose License audit, maintenance status (per-package hex-deps-triager only)

Incremental Mode (--since <commit>)

Analyze only changes since a specific commit. Useful for pre-merge checks:

Run git diff --name-only <commit>...HEAD to identify changed files, then run targeted audits on changed files only (skips full project scan).

Combines with other flags: /phx:audit --since HEAD~5 --focus=security

Relationship to Other Commands

Command Scope Frequency
/phx:review Changed files (diff) Every PR
/phx:audit Entire project Quarterly
/phx:boundaries Context structure On-demand
/phx:verify Compile/test pass Anytime

References

  • ${CLAUDE_SKILL_DIR}/references/scoring-methodology.md - How scores are calculated
  • ${CLAUDE_SKILL_DIR}/references/architecture-checks.md - Detailed architecture criteria
Files (claude-elixir-phoenix)
  • references
    • architecture-checks.md 5.1 KB
      # Architecture Checks Reference
      
      Detailed criteria for architecture health assessment.
      
      ## Context Health Matrix
      
      ### What to Check
      
      For each context in `lib/{app}/`:
      
      | Metric | Healthy Range | Red Flag |
      |--------|---------------|----------|
      | Modules per context | 3-15 | >20 or <2 |
      | Public API functions | 5-30 | >40 |
      | Schemas per context | 1-5 | >8 |
      | Fan-out (contexts called) | 1-4 | >6 |
      | Fan-in (called by contexts) | 1-6 | >10 |
      
      ### Commands
      
      ```bash
      # Module count per context
      for dir in lib/my_app/*/; do
        echo "$(basename $dir): $(find $dir -name '*.ex' | wc -l) modules"
      done
      
      # Public function count
      grep -r "^  def " lib/my_app/*.ex --include="*.ex" | wc -l
      
      # Schema count
      grep -rl "use Ecto.Schema" lib/my_app/ | wc -l
      
      # Fan-out via xref
      mix xref graph --format stats
      ```
      
      ## Coupling Analysis
      
      ### Fan-Out (Efferent Coupling)
      
      How many other contexts does this context depend on?
      
      ```bash
      # For each context, count outgoing dependencies
      mix xref graph --label compile-connected --format dot | grep "my_app_accounts ->"
      ```
      
      | Fan-Out | Assessment |
      |---------|------------|
      | 0-2 | Excellent - well isolated |
      | 3-4 | Good - reasonable dependencies |
      | 5-6 | Warning - consider splitting |
      | 7+ | Critical - "god context" |
      
      ### Fan-In (Afferent Coupling)
      
      How many contexts depend on this context?
      
      | Fan-In | Assessment |
      |--------|------------|
      | 0 | Dead code? Or utility only |
      | 1-4 | Good - clear responsibility |
      | 5-8 | Common utility - ensure stable API |
      | 9+ | Core abstraction - avoid changes |
      
      ## Cohesion Analysis
      
      ### Signs of Low Cohesion
      
      - Context name is generic ("Utils", "Helpers", "Services")
      - Functions don't share domain vocabulary
      - Multiple unrelated schemas in same context
      - Context has >50 public functions
      
      ### Assessment
      
      ```bash
      # Check for generic names
      ls lib/my_app/ | grep -E "utils|helpers|services|common|shared"
      
      # Large API surface
      for file in lib/my_app/*.ex; do
        funcs=$(grep -c "^  def " "$file" 2>/dev/null || echo 0)
        if [ "$funcs" -gt 30 ]; then
          echo "WARNING: $(basename $file) has $funcs public functions"
        fi
      done
      ```
      
      ## Boundary Violations
      
      ### Types of Violations
      
      | Violation | Severity | Example |
      |-----------|----------|---------|
      | Direct Repo from web | High | `Web.Controller` calls `Repo.all` |
      | Cross-context schema import | Medium | `Orders` aliases `Accounts.User` |
      | Direct schema access | Medium | `%Accounts.User{}` outside Accounts |
      | Context calling _web module | High | Business logic → presentation |
      
      ### Detection
      
      ```bash
      # Repo calls outside contexts
      grep -rn "Repo\." lib/my_app_web/ --include="*.ex"
      
      # Cross-context schema aliases
      grep -rn "alias MyApp\." lib/my_app/ --include="*.ex" | grep -v "alias MyApp\.$(dirname)"
      ```
      
      ## Circular Dependencies (Compile-Time)
      
      Runtime cycles (e.g., from `verified_routes()`) are benign and don't cause recompilation cascades.
      Only compile-time cycles affect build performance and are scored.
      
      ### Detection
      
      ```bash
      mix xref graph --format cycles --label compile
      ```
      
      ### Assessment
      
      | Cycles | Assessment |
      |--------|------------|
      | 0 | Excellent |
      | 1-2 | Warning - analyze and fix |
      | 3+ | Critical - architectural issue |
      
      ### Resolution Patterns
      
      1. **Extract shared module** - Move shared code to new context
      2. **Behavior/protocol** - Define interface, implement separately
      3. **Event-driven** - Replace direct calls with PubSub
      4. **Merge contexts** - If truly coupled, they're one context
      
      ## Naming Conventions
      
      ### Module Naming
      
      | Pattern | Assessment |
      |---------|------------|
      | `MyApp.{Domain}.{Entity}` | Correct |
      | `MyApp.{Domain}Service` | Avoid "Service" suffix |
      | `MyApp.{Domain}Manager` | Avoid "Manager" suffix |
      | `MyApp.{Domain}Helper` | Move to domain context |
      
      ### Function Naming
      
      | Pattern | Assessment |
      |---------|------------|
      | `get_user/1` | Correct - raises |
      | `fetch_user/1` | Correct - returns tuple |
      | `list_users/0` | Correct |
      | `find_user/1` | Inconsistent - use get/fetch |
      | `user/1` | Too vague |
      
      ### Context API Surface
      
      Well-designed context has:
      
      ```elixir
      defmodule MyApp.Accounts do
        # Queries (list/get/fetch)
        def list_users(opts \\ [])
        def get_user!(id)
        def fetch_user(id)
      
        # Commands (create/update/delete)
        def create_user(attrs)
        def update_user(user, attrs)
        def delete_user(user)
      
        # Domain operations
        def authenticate(email, password)
        def verify_email(token)
      end
      ```
      
      ## Output Format
      
      ```markdown
      ## Architecture Review
      
      ### Context Health Matrix
      
      | Context | Modules | Public API | Fan-Out | Fan-In | Assessment |
      |---------|---------|------------|---------|--------|------------|
      | Accounts | 5 | 12 | 2 | 4 | Healthy |
      | Orders | 18 | 45 | 8 | 3 | Too Large |
      | Shared | 2 | 8 | 0 | 12 | Utility OK |
      
      ### Boundary Violations
      
      | Type | Location | Severity |
      |------|----------|----------|
      | Direct Repo | post_controller.ex:45 | High |
      
      ### Circular Dependencies
      
      - None found ✅
      
      ### Recommendations
      
      1. **Split Orders context** - 18 modules is too large
         - Extract Fulfillment (shipping, tracking)
         - Extract Invoicing (billing, receipts)
      
      2. **Fix boundary violation** - Move Repo call to context
         - `PostController.create/2` should call `Blog.create_post/1`
      ```
      
    • scoring-methodology.md 4.3 KB
      # Scoring Methodology
      
      How health scores are calculated for each category.
      
      ## Score Ranges
      
      | Score | Grade | Status | Meaning |
      |-------|-------|--------|---------|
      | 90-100 | A | Excellent | No critical issues, minor improvements only |
      | 80-89 | B | Good | Few warnings, solid foundation |
      | 70-79 | C | Needs Attention | Some issues to address |
      | 60-69 | D | Needs Work | Multiple issues, prioritize fixing |
      | <60 | F | Critical | Significant problems, immediate action |
      
      ## Category Scoring
      
      ### Architecture (100 points)
      
      | Criterion | Points | Deductions |
      |-----------|--------|------------|
      | Context boundaries respected | 25 | -5 per violation |
      | Module naming consistency | 15 | -3 per inconsistency |
      | Fan-out <5 contexts per module | 15 | -5 per over-coupled module |
      | API surface reasonable (<30 funcs/context) | 15 | -5 per bloated context |
      | No compile-time circular dependencies | 15 | -10 per cycle |
      | Folder structure follows conventions | 15 | -5 per deviation |
      
      **Commands used:**
      
      ```bash
      mix xref graph --format stats
      mix xref graph --format cycles --label compile
      find lib -name "*.ex" -type f | wc -l
      ```
      
      ### Performance (100 points)
      
      | Criterion | Points | Deductions |
      |-----------|--------|------------|
      | No N+1 patterns detected | 30 | -5 per N+1 |
      | Indexes for common queries | 20 | -5 per missing index |
      | Preloads used appropriately | 15 | -3 per missing preload |
      | No GenServer bottlenecks | 15 | -10 per bottleneck |
      | LiveView streams for large lists | 10 | -5 per regular assign list |
      | Queries avoid SELECT * | 10 | -2 per SELECT * |
      
      **Commands used:**
      
      ```bash
      grep -B5 -A5 "Enum.map" lib/ -r --include="*.ex" | grep "Repo\."
      grep -r "Repo.preload" lib/ --include="*.ex"
      grep -r "assign(socket" lib/my_app_web/live/ --include="*.ex"
      ```
      
      ### Security (100 points)
      
      | Criterion | Points | Deductions |
      |-----------|--------|------------|
      | No sobelow critical issues | 30 | -15 per critical |
      | No sobelow high issues | 20 | -5 per high |
      | Authorization in all handle_events | 15 | -10 per missing auth |
      | No String.to_atom with input | 10 | -10 per violation |
      | No raw() with untrusted content | 10 | -10 per violation |
      | Secrets in runtime.exs only | 15 | -15 per hardcoded secret |
      
      **Commands used:**
      
      ```bash
      mix sobelow --exit medium 2>&1 || true
      grep -r "String.to_atom" lib/ --include="*.ex"
      grep -r "raw(" lib/ --include="*.ex"
      grep -r "handle_event" lib/my_app_web/live/ -A10 | grep -v "authorize\|permit"
      ```
      
      ### Test Quality (100 points)
      
      | Criterion | Points | Deductions |
      |-----------|--------|------------|
      | Coverage >70% | 30 | -5 per 10% below 70% |
      | No flaky test patterns | 20 | -5 per Process.sleep in test |
      | Async: true where possible | 15 | -2 per missing async |
      | verify_on_exit! in Mox tests | 15 | -5 per missing |
      | Reasonable test duration (<30s avg) | 10 | -5 if slow |
      | Error paths tested | 10 | -5 if only happy path |
      
      **Commands used:**
      
      ```bash
      mix test --cover 2>&1 | tail -30
      grep -r "Process.sleep" test/ --include="*.exs"
      grep -r "async: true" test/ --include="*.exs"
      grep -r "verify_on_exit!" test/ --include="*.exs"
      ```
      
      ### Dependencies (100 points)
      
      | Criterion | Points | Deductions |
      |-----------|--------|------------|
      | No hex.audit vulnerabilities | 40 | -20 per vulnerability |
      | No deps.audit issues | 20 | -10 per issue |
      | No major version behind (>2) | 20 | -5 per outdated |
      | No unused dependencies | 10 | -3 per unused |
      | Version pinning appropriate | 10 | -5 if all loose |
      
      **Commands used:**
      
      ```bash
      mix hex.audit 2>&1
      mix deps.audit 2>&1
      mix hex.outdated 2>&1
      ```
      
      ## Overall Score Calculation
      
      ```
      overall_score = (
        architecture_score * 0.20 +
        performance_score * 0.25 +
        security_score * 0.25 +
        test_quality_score * 0.15 +
        dependencies_score * 0.15
      )
      ```
      
      **Weighting rationale:**
      
      - Security and Performance weighted highest (25% each) - runtime impact
      - Architecture weighted at 20% - long-term maintainability
      - Tests and Dependencies at 15% each - important but less immediate
      
      ## Grade Assignment
      
      ```
      if overall_score >= 90: grade = "A"
      elif overall_score >= 80: grade = "B"
      elif overall_score >= 70: grade = "C"
      elif overall_score >= 60: grade = "D"
      else: grade = "F"
      ```
      
      ## Critical Issues Override
      
      Regardless of score, flag as CRITICAL if any:
      
      - Security vulnerability detected
      - Hardcoded secrets found
      - Compile warnings present
      - Test suite failing
      
  • SKILL.md 7.9 KB
    ---
    name: audit
    description: Project health audit and health check — architecture, performance, tests, dependencies, code quality. Use when assessing overall project health, before releases, or after refactors.
    effort: high
    argument-hint: "[--quick|--full|--focus=area|--since=commit]"
    ---
    
    # Project Health Audit
    
    Comprehensive project-wide health assessment using 5 parallel specialist subagents.
    
    ## Usage
    
    ```
    /phx:audit              # Full audit (default)
    /phx:audit --quick      # 2-3 minute pulse check
    /phx:audit --focus=security   # Deep dive single area
    /phx:audit --focus=performance
    /phx:audit --since abc123   # Incremental audit since commit
    /phx:audit --since HEAD~10  # Audit last 10 commits
    ```
    
    ## When to Use
    
    - **Quarterly** health checks
    - **Before major releases**
    - **After large refactors**
    - **New team member onboarding** (understand codebase health)
    
    ## Iron Laws
    
    1. **Wait for ALL agents before synthesizing** — Partial results create misleading health scores because cross-category correlations get missed
    2. **Scope agent prompts to specific directories** — Vague prompts like "analyze the codebase" produce generic findings that waste tokens and miss real issues
    3. **Never compare scores across projects** — Scoring methodology depends on project size and maturity; only track trends within the same project
    4. **Quick mode before full mode** — Run `--quick` first to catch compile/test failures before spending tokens on 5 parallel agents
    
    ## Subagent Architecture
    
    Spawn 5 specialists in parallel using Agent tool. Three route to plugin
    specialists with a declared model; the two categories without a specialist use
    `general-purpose` pinned to `model: "sonnet"` — unpinned, they inherit the
    session model (Opus by default):
    
    | Subagent | Focus | Output File | Routes to |
    |----------|-------|-------------|-----------|
    | Architecture Reviewer | Structure quality, coupling, cohesion | `arch-review.md` | `phoenix-patterns-analyst` (sonnet) |
    | Performance Auditor | N+1, indexes, bottlenecks, scalability | `perf-audit.md` | `general-purpose`, `model: "sonnet"` (no perf specialist yet) |
    | Security Auditor | OWASP scan, auth patterns, secrets | `security-audit.md` | `security-analyzer` (opus) |
    | Test Health Auditor | Coverage, quality, flaky tests | `test-audit.md` | `testing-reviewer` (sonnet) |
    | Dependency Auditor | Vulnerabilities, outdated, unused | `deps-audit.md` | `general-purpose`, `model: "sonnet"` (`hex-deps-triager` is per-package only) |
    
    ## Workflow
    
    ### Step 1: Create Task List and Spawn All 5 Auditors (Parallel)
    
    **If `TaskCreate` is in your tool list**, create Claude Code tasks for
    progress visibility (Sonnet 5+ and Opus 4.8+ omit it unless
    `CLAUDE_CODE_ENABLE_TODO_TOOLS=1`; never ToolSearch for it — skip this block):
    
    ```
    For each auditor:
      TaskCreate({subject: "{Area} audit", activeForm: "Auditing {area}..."})
      TaskUpdate({taskId, status: "in_progress"})
    ```
    
    Then spawn all 5 agents with Agent tool (parallel). Route to declared-model
    specialists where they exist, keep `general-purpose` only where no specialist
    covers the audit category:
    
    ```
    Agent(subagent_type: "phx:phoenix-patterns-analyst", prompt: "Architecture audit: analyze module structure, context boundaries, coupling, cohesion. Write findings to .claude/audit/reports/arch-review.md", run_in_background: true)
    Agent(subagent_type: "general-purpose", model: "sonnet", prompt: "Performance audit: N+1 queries, missing indexes, bottlenecks, scalability. Write findings to .claude/audit/reports/perf-audit.md", run_in_background: true)
    Agent(subagent_type: "phx:security-analyzer",        prompt: "Security audit: OWASP scan, auth patterns, secret leakage. Write findings to .claude/audit/reports/security-audit.md", run_in_background: true)
    Agent(subagent_type: "phx:testing-reviewer",         prompt: "Test health audit: coverage, quality, flakes. Write findings to .claude/audit/reports/test-audit.md", run_in_background: true)
    Agent(subagent_type: "general-purpose", model: "sonnet", prompt: "Dependency audit: vulnerabilities, outdated, unused. Write findings to .claude/audit/reports/deps-audit.md", run_in_background: true)
    ```
    
    **Why specialist routing matters**: a `general-purpose` subagent without
    `model:` inherits the session model — Opus on every plan since CC 2.1.280.
    Plugin specialists declare their own model in frontmatter, and the two
    `general-purpose` tracks pin `model: "sonnet"`, so no audit track runs on Opus.
    
    **Agent prompts must be FOCUSED.** Scope each prompt to the
    relevant directories and patterns. Do NOT give vague prompts
    like "analyze the codebase."
    
    **Output efficiency**: Tell each agent: "Report ONLY issues found.
    Do NOT list clean checks, passing categories, or 'What's Good'.
    One summary line per clean area suffices."
    
    ### Step 2: Collect Results
    
    Wait for ALL auditors to complete — one completion notification per agent
    spawned. If you created tasks, mark each `completed` as it finishes. NEVER
    proceed while any auditor is still running.
    
    Read reports from `.claude/audit/reports/`.
    
    **Rate-limit circuit breaker:** if 2+ auditors return empty results or
    rate-limit/API errors, STOP spawning. Synthesize from the reports that
    exist, mark missing categories as "not audited (rate limit)", and tell
    the user to re-run `/phx:audit` after the limit resets. Never leave the
    user typing "continue" against dead agents.
    
    ### Step 3: Compress Findings
    
    After all 5 auditors complete, spawn context-supervisor:
    
    ```
    Agent(subagent_type: "phx:context-supervisor", prompt: """
    Compress audit findings.
    Input: .claude/audit/reports/
    Output: .claude/audit/summaries/
    Priority: Health scores per category, critical findings
    only, cross-category correlations, deduplicate findings
    found by 2+ agents.
    """)
    ```
    
    Read `.claude/audit/summaries/consolidated.md` for synthesis.
    
    ### Step 4: Calculate Health Score
    
    Each category scores 0-100. See `${CLAUDE_SKILL_DIR}/references/scoring-methodology.md`.
    
    ### Step 5: Generate Report
    
    Write to `.claude/audit/summaries/project-health-{date}.md`.
    
    ## Output Format
    
    Report includes: Executive summary with health score (A-F, numeric/100),
    per-category score table (Architecture, Performance, Security, Tests, Dependencies),
    critical issues, top recommendations, and action plan (Immediate/Short-term/Long-term).
    
    ## Quick Mode (`--quick`)
    
    Only run essential checks (~2-3 minutes):
    
    Run `mix compile --warnings-as-errors`, then `mix hex.audit && mix deps.audit`,
    then `mix xref graph --format stats`, then `mix test --trace 2>&1 | tail -20`.
    
    Skip: Full security scan, N+1 analysis, test quality metrics, architecture deep dive.
    
    ## Focus Mode (`--focus=area`)
    
    Deep dive single area with full specialist resources:
    
    | Focus | Subagent | Extra Checks |
    |-------|----------|--------------|
    | `security` | security-analyzer | Full OWASP, sobelow, manual patterns |
    | `performance` | general-purpose | Profile-level analysis, query explain (no plugin specialist yet) |
    | `architecture` | phoenix-patterns-analyst | Full xref, coupling matrix, cohesion |
    | `tests` | testing-reviewer | Coverage by context, quality metrics |
    | `deps` | general-purpose | License audit, maintenance status (per-package `hex-deps-triager` only) |
    
    ## Incremental Mode (`--since <commit>`)
    
    Analyze only changes since a specific commit. Useful for pre-merge checks:
    
    Run `git diff --name-only <commit>...HEAD` to identify changed files, then run targeted audits on changed files only (skips full project scan).
    
    Combines with other flags: `/phx:audit --since HEAD~5 --focus=security`
    
    ## Relationship to Other Commands
    
    | Command | Scope | Frequency |
    |---------|-------|-----------|
    | `/phx:review` | Changed files (diff) | Every PR |
    | `/phx:audit` | Entire project | Quarterly |
    | `/phx:boundaries` | Context structure | On-demand |
    | `/phx:verify` | Compile/test pass | Anytime |
    
    ## References
    
    - `${CLAUDE_SKILL_DIR}/references/scoring-methodology.md` - How scores are calculated
    - `${CLAUDE_SKILL_DIR}/references/architecture-checks.md` - Detailed architecture criteria
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related