axiom-health-check
- Repo stars 977
- Forks 74
- License MIT
- Author updated Jun 15, 2026, 03:09 AM
- Author repo Axiom
- Domain
- Security
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 94 / 100 · audit passed
- Author / version / license
- @CharlesWiltgen · MIT
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Shell exec
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: axiom-health-check
description: Use when the user wants a comprehensive project-wide audit, full health check, or scan across al…
category: security
runtime: no special runtime
---
# axiom-health-check output preview
## PART A: Task fit
- Use case: Use when the user wants a comprehensive project-wide audit, full health check, or scan across all domains. You are an orchestrator that launches specialized Axiom auditors in parallel, collects their findings, deduplicates by file:line, and produces a unified health report. runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Files to Exclude / Phase 0: Determine Audit Scope and User Intent / DIFF SCOPE block” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Use when the user wants a comprehensive project-wide audit, full health check, or scan across all domains. You are an orchestrator that launches specialized Axiom auditors in parallel, collects their findings, deduplicates by file:line, and produces a unified health report. runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “Files to Exclude / Phase 0: Determine Audit Scope and User Intent / DIFF SCOPE block” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options.The source mentions slash commands such as `/axiom`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, run shell commands.
Start with a small task and check whether the result follows “Files to Exclude / Phase 0: Determine Audit Scope and User Intent / DIFF SCOPE block”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: axiom-health-check
description: Use when the user wants a comprehensive project-wide audit, full health check, or scan across al…
category: security
source: CharlesWiltgen/Axiom
---
# axiom-health-check
## When to use
- Use when the user wants a comprehensive project-wide audit, full health check, or scan across all domains. You are an…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Files to Exclude / Phase 0: Determine Audit Scope and User Intent / DIFF SCOPE block” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies.The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "axiom-health-check" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Files to Exclude / Phase 0: Determine Audit Scope and User Intent / DIFF SCOPE block
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files, run shell commands | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}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 0: Determine Audit Scope and User Intent
Before anything else, parse the launch prompt for three optional blocks emitted by the /axiom:health-check command:
DIFF SCOPE block
DIFF SCOPE
Base ref: <base>
Merge-base: <full-SHA>
Changed Swift files (N):
<paths>Determines the audit's file universe:
- Full audit (default). No
DIFF SCOPEblock. Phase 1 globs the whole project; Phase 2 lets each auditor scan freely; Phase 4 reports "Scope: full project audit." - Diff-scoped audit. A
DIFF SCOPEblock is present. The provided file list is the universe — Phase 1 uses it directly (no Glob), Phase 2 forwards it to every auditor as a hard constraint, and Phase 4 declares the scope in the report header.
EXCLUSIONS line
EXCLUSIONS: skip <auditor>, skip <auditor> — drop the listed auditors from Phase 1's run list. Acknowledge them in the user-facing summary.
USER EMPHASIS line
USER EMPHASIS: <freeform text> — the user told you what they care about most (e.g., "focus on memory leaks", "worried about Core Data migrations", "prioritize accessibility").
Emphasis affects ordering and highlighting, never inclusion or exclusion:
- It does NOT change which auditors run. Always-run auditors still run. Conditional auditors still trigger by signal. Exclusions still apply.
- It DOES change Phase 4's executive summary — surface findings that match the emphasis first, even if their severity is lower than other findings.
- It DOES affect the summary table's ordering — emphasized domains appear at the top.
If no USER EMPHASIS block is present, fall back to severity-only ordering.
Record the mode (full vs diff-scoped), scope metadata (base ref, merge-base SHA, file list, count), exclusions, and emphasis text. Subsequent phases reference this.
Phase 1: Detect Which Auditors to Run
Gather the Swift-file universe according to Phase 0 mode:
- Full audit: Glob
**/*.swift. - Diff-scoped audit: Use the file list from the
DIFF SCOPEblock. Do NOT Glob — the launcher already enumerated the relevant files.
Then use Grep over that file set 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 |
|---|---|
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
Dispatch one Agent call per auditor selected in Phase 1. Do not merge auditors, skip them, or run their scans inline. N selected → N Agent calls 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).
If diff-scoped (Phase 0), prepend a scope block to every auditor's launch prompt verbatim:
DIFF SCOPE
Only audit the files listed below. Do NOT report findings outside this list, even if your Glob would otherwise match them. Treat this list as the complete universe of source files for this audit.
Files (N):
<paths>The file list is the same one from Phase 0. Auditors will narrow their Glob accordingly, which is the entire reason this mode is fast — no wasted scan of unchanged files.
While auditors run, inform the user:
- Audit scope (full vs
diff vs <base>, plus file count if diff-scoped) - 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
scratch/health-check-*-{date}.mdfile - 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 (full audit) or scratch/health-check-diff-{date}.md (diff-scoped) with:
Scope (always the first section)
- Full audit:
Scope: full project audit (N Swift files) - Diff-scoped:
Scope: changed files vs `<base>` (merge-base `<short-SHA>`, N files), followed by the bulleted file list.
This makes it unambiguous to the reader (and to any PR reviewer pasting the report into a comment) what was and wasn't inspected.
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
- 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
- In diff-scoped mode, drop any finding whose file path is not in the Phase 0 file list before deduplicating — auditors may slip and report adjacent files. The scope is a hard boundary.
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
Decide Fit First
Design Intent
How To Use It
Boundaries And Review