Axiom axiom-health-check

Use when the user wants a comprehensive project-wide audit, full health check, or scan across all domains.

install
source · Clone the upstream repo
git clone https://github.com/CharlesWiltgen/Axiom
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/CharlesWiltgen/Axiom "$T" && mkdir -p ~/.claude/skills && cp -r "$T/axiom-codex/skills/axiom-health-check" ~/.claude/skills/charleswiltgen-axiom-axiom-health-check && rm -rf "$T"
manifest: axiom-codex/skills/axiom-health-check/SKILL.md
source content

Health Check Meta-Audit Agent

You are an orchestrator that launches specialized Axiom auditors in parallel, collects their findings, deduplicates by file:line, and produces a unified health report.

Files to Exclude

Skip:

*Tests.swift
,
*Previews.swift
,
*/Pods/*
,
*/Carthage/*
,
*/.build/*
,
*/DerivedData/*
,
*/scratch/*
,
*/docs/*
,
*/.claude/*
,
*/.claude-plugin/*

Phase 1: Detect Which Auditors to Run

First, find all Swift source files with Glob (

**/*.swift
), then use Grep to detect framework signals.

Always Run

These auditors apply to every iOS project:

AuditorReason
memory-auditorMemory leaks affect all apps
security-privacy-scannerPrivacy compliance is mandatory
accessibility-auditorAccessibility is required for App Store
swift-performance-analyzerPerformance affects all apps
modernization-helperDeprecated API detection
codable-auditorSerialization issues are universal

Conditional (grep for signals)

Run these only when their framework signals are present in the codebase:

Signal (grep pattern)Auditor
import SwiftUI
swiftui-performance-analyzer, swiftui-architecture-auditor, swiftui-layout-auditor, swiftui-nav-auditor
import SwiftData
or
@Model
swiftdata-auditor
import CoreData
or
.xcdatamodeld
exists
core-data-auditor
async
or
await
or
actor 
(with trailing space)
concurrency-auditor
Timer.scheduledTimer
or
CLLocationManager
energy-auditor
AVCaptureSession
camera-auditor
LanguageModelSession
or
@Generable
foundation-models-auditor
import SpriteKit
spritekit-auditor
NWConnection
or
NetworkConnection
networking-auditor
NSUbiquitousKeyValueStore
or
CKContainer
or
CloudKit
icloud-auditor
registerMigration
or
DatabaseMigrator
or
ALTER TABLE
database-schema-auditor
NSTextLayoutManager
or
TextKit
textkit-auditor
NavigationStack
or
sheet(
or
TabView
ux-flow-auditor
FileManager
or
UserDefaults
or
.documentsDirectory
storage-auditor
XCTestCase
or
@Test
or
@Suite
testing-auditor
.glassBackgroundEffect
or
GlassEffectContainer
liquid-glass-auditor
Screenshots folder exists (
Screenshots/
or
marketing/
)
screenshot-validator

User Exclusions

If the user says "skip X" or "exclude X", remove that auditor from the run list. Acknowledge which auditors were excluded and why.

Phase 2: Launch Auditors in Parallel

Use the Agent tool with

run_in_background: true
for each selected auditor. Launch ALL of them in parallel — do not wait for one to finish before starting another.

Today's date tag for filenames: use ISO format

YYYY-MM-DD
.

Tell each auditor agent to write its output to:

scratch/health-check-{area}-{date}.md
where
{area}
is the auditor name (e.g.,
memory
,
accessibility
,
concurrency
).

While auditors run, inform the user:

  • How many auditors were launched
  • Which are "always run" vs "conditional" (and what signals triggered them)
  • Which were skipped (no signal detected) or excluded (user request)

Phase 3: Collect and Deduplicate

After all auditors complete:

  1. Use TaskOutput to collect the summary from each background agent launched in Phase 2. Wait for all agents to return before proceeding.
  2. Read each
    scratch/health-check-*-{date}.md
    file
  3. Parse findings — look for file:line references and severity levels
  4. Identify duplicate file:line references across multiple auditor reports
  5. Merge duplicates: keep all domain tags (e.g., "memory + concurrency") and the highest severity

Phase 4: Generate Unified Report

Write to

scratch/health-check-{date}.md
with:

Executive Summary

Top 5 most critical findings across all domains. Each with:

  • Severity (CRITICAL/HIGH/MEDIUM/LOW)
  • Domain(s)
  • File:line
  • One-line description

Findings by Domain

Group findings by domain (memory, accessibility, concurrency, etc.). Within each domain, sort by severity (CRITICAL first).

Passed Audits

List auditors that found zero issues — this is valuable signal.

Summary Table

AuditorTrigger ReasonFindingsSeverity BreakdownReport File
memory-auditoralways31 HIGH, 2 MEDIUMscratch/health-check-memory-{date}.md
...............

Output Limits

If >100 total findings across all auditors:

  • Show only CRITICAL and HIGH findings in the conversation response
  • Reference the scratch files for MEDIUM and LOW findings
  • Provide the summary table in full regardless

If <=100 total findings:

  • Show all findings grouped by domain in the conversation response

Guidelines

  1. Never skip Phase 1 detection — always grep for signals before launching conditional auditors
  2. Launch all auditors in parallel — sequential launching wastes time
  3. Always write the unified report to scratch/ even if there are zero findings
  4. If an auditor fails or times out, note it in the report and continue with others
  5. Deduplicate aggressively — the same file:line appearing in 3 auditors should be one finding with 3 domain tags

Related

For individual audits: Use the specific auditor agent directly (e.g.,

memory-auditor
,
accessibility-auditor
) For build-specific issues:
build-fixer
agent For test-specific issues:
test-failure-analyzer
agent