Axiom axiom-health-check
Use when the user wants a comprehensive project-wide audit, full health check, or scan across all domains.
git clone https://github.com/CharlesWiltgen/Axiom
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"
axiom-codex/skills/axiom-health-check/SKILL.mdHealth 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:
| Auditor | Reason |
|---|---|
| memory-auditor | Memory leaks affect all apps |
| security-privacy-scanner | Privacy compliance is mandatory |
| accessibility-auditor | Accessibility is required for App Store |
| swift-performance-analyzer | Performance affects all apps |
| modernization-helper | Deprecated API detection |
| codable-auditor | Serialization issues are universal |
Conditional (grep for signals)
Run these only when their framework signals are present in the codebase:
| Signal (grep pattern) | Auditor |
|---|---|
| swiftui-performance-analyzer, swiftui-architecture-auditor, swiftui-layout-auditor, swiftui-nav-auditor |
or | swiftdata-auditor |
or exists | core-data-auditor |
or or (with trailing space) | concurrency-auditor |
or | energy-auditor |
| camera-auditor |
or | foundation-models-auditor |
| spritekit-auditor |
or | networking-auditor |
or or | icloud-auditor |
or or | database-schema-auditor |
or | textkit-auditor |
or or | ux-flow-auditor |
or or | storage-auditor |
or or | testing-auditor |
or | liquid-glass-auditor |
Screenshots folder exists ( or ) | 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:
- Use TaskOutput to collect the summary from each background agent launched in Phase 2. Wait for all agents to return before proceeding.
- Read each
filescratch/health-check-*-{date}.md - Parse findings — look for file:line references and severity levels
- Identify duplicate file:line references across multiple auditor reports
- 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
| Auditor | Trigger Reason | Findings | Severity Breakdown | Report File |
|---|---|---|---|---|
| memory-auditor | always | 3 | 1 HIGH, 2 MEDIUM | scratch/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
- Never skip Phase 1 detection — always grep for signals before launching conditional auditors
- Launch all auditors in parallel — sequential launching wastes time
- Always write the unified report to scratch/ even if there are zero findings
- If an auditor fails or times out, note it in the report and continue with others
- 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