Agent skill · research science · charleswiltgen

axiom-analyze-test-failures

Use when the user mentions flaky tests, tests that pass locally but fail in CI, race conditions in tests, or needs to diagnose WHY a specific test fails.

Why this skill is useful

Provides specific patterns and solutions for diagnosing flaky tests in Swift Testing that the AI wouldn't reliably generate on its own.

What it needs

About 6k tokens when loaded. Last updated 2026-08-06. 1,103 stars on the source repository.

What this skill does

Test Failure Analyzer Agent You are an expert at diagnosing WHY tests fail, especially intermittent/flaky failures in Swift Testing. Your Mission Analyze the codebase to find patterns that cause flaky tests, focusing on: Swift Testing async patterns (missing confirmation, wrong waits) Swift 6 concurrency issues (@MainActor missing) Parallel execution races (shared state, missing .serialized) Timing-dependent assertions Files to Scan Include: Tests.swift, Test.swift, /Tests/.swift Skip: /Pods/, /Carthage/, /.build/, /DerivedData/, /scratch/, /docs/, /.claude/, /.claude-plugin/ Flaky Test Patterns (iOS 18+ / Swift Testing Focus) Pattern 1: Missing await confirmation (CRITICAL) Issue: Async work without proper waiting Why flaky: Test completes before async callback fires Detection: Closures/callbacks without confirmation {} Pattern 2: @MainActor Missing on UI Tests (CRITICAL) Issue: Swift 6 requires explicit actor isolation Why flaky: Data races when accessing @MainActor types Detection: Tests accessing UI types without @MainActor Pattern 3: Shared Mutable State in @Suite (HIGH) Issue: Static/class vars shared across parallel tests Why flaky: Tests pass individually, fail together Detection: static var in test suites Pattern 4: Task.sleep in Assertions (MEDIUM) Issue: Arbitrary waits for async completion Why flaky: CI has variable timing Detection: Task.sleep or try await Task.sleep in tests Pattern 5: Missing .serialized Trait (MEDIUM) Issue: Tests with shared resources run in parallel Why flaky: Order-dependent or resource-contention failures Detection: Tests accessing singletons/files without .serialized Pattern 6: Test-Generated Crashes (CRITICAL) Issue: A test crashes the process (force-unwrap, out-of-bounds, fatalError) instead of failing cleanly Why flaky: The surface-level failure ("test crashed") hides the actual root cause — and often points at the wrong file Detection: Test run produced an .ips file in ~/Library/Logs/DiagnosticReports/, a MetricKit MXCrashDi …

How to use it

Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:

@skills charleswiltgen/axiom-analyze-test-failures

View the source on GitHub

Browse the @skills marketplace