axiom-debug-tests

Use this agent for closed-loop test debugging - automatically analyzes test failures, suggests fixes, and re-runs tests until passing.

Quality

70%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./axiom-codex/skills/axiom-debug-tests/SKILL.md

Quality

Content

70%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The content is a highly actionable, well-sequenced closed-loop debugging workflow with strong validation and feedback loops. Its main weaknesses are repetition of the element-not-found guidance across several sections and a lack of progressive disclosure into separate reference files.

Suggestions

Consolidate the repeated 'Element Not Found' guidance into a single triage block and have the pattern table, fix section, and quick reference point to it rather than restating it.

Split the pattern/fix reference tables and the Phase 7 report template into a references/ file (e.g. FIX-PATTERNS.md) and link to it, reducing the inline wall of text.

Fill or document the <SCHEME_NAME>/<TARGET> placeholders with a concrete example value to push actionability toward fully copy-paste-ready.

Dimension	Reasoning	Score
Conciseness	The body is dense and free of concept-explanation fluff, but the 'Element Not Found' material is repeated across the failure-pattern table, a dedicated triage subsection, the Phase 4 fix, the Error Quick Reference, and the decision tree, and the full Phase 7 report template adds length that could be tightened.	3 / 5
Actionability	Executable bash (xcodebuild, xcrun xcresulttool, xcsym) and complete BEFORE/AFTER Swift fix examples cover the common cases, but parameterization placeholders like <SCHEME_NAME>UITests and <path-to-ips>, plus a couple of high-level steps ('Read the test code', 'Search the app source'), leave minor gaps short of fully copy-paste-ready.	4 / 5
Workflow Clarity	A clear closed-loop sequence (RUN -> CAPTURE -> ANALYZE -> SUGGEST -> FIX -> VERIFY -> REPORT) is laid out in numbered phases with explicit validation (Phase 6 re-run), a feedback loop for error recovery, a decision tree, and a 'max 3 iterations then escalate' checkpoint.	5 / 5
Progressive Disclosure	The ~320-line body is well sectioned but entirely inline with no bundle files (references/, scripts/, assets/ are absent); pattern tables and fix recipes that could live in separate reference files are monolithic, and the only signaled reference (skills/xcsym-ref.md) is an external skill rather than this skill's own bundle.	3 / 5
	Total	15 / 20 Passed

Description

70%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description clearly states concrete capabilities and an equivalent 'when' trigger, but the second-person 'Use this' phrasing incurs a voice penalty and the trigger is somewhat generic. Strong but not exemplary.

Suggestions

Rewrite in third person to avoid the voice penalty, e.g. 'Analyzes test failures, suggests fixes, and re-runs tests until passing. Use when iOS UI tests fail and need closed-loop debugging.'

Add concrete trigger phrases a user would naturally say, such as 'failing tests', 'broken UI tests', or 'test failures', to broaden keyword coverage.

Surface the iOS/xcodebuild specificity and key sub-actions (crash symbolication, screenshot triage) to lift specificity toward 5.

Dimension	Reasoning	Score
Specificity	The description lists several concrete actions ('analyzes test failures, suggests fixes, and re-runs tests until passing') which would anchor at 4, but the second-person imperative 'Use this agent for...' triggers the rubric's -1 voice penalty, capping it at 3; it also omits iOS-specific actions like crash symbolication or screenshot analysis that would be needed for a 5.	3 / 5
Completeness	Both 'what' (analyze failures, suggest fixes, re-run) and a 'when'-equivalent trigger ('Use this agent for closed-loop test debugging') are present, but the 'when' is generic and could name the concrete trigger (when UI tests fail) more explicitly to reach 5.	4 / 5
Trigger Term Quality	Natural terms a user would say are present ('test debugging', 'test failures', 'fixes', 're-runs tests'), giving good keyword coverage, though common synonyms like 'failing/broken tests' are missing.	4 / 5
Distinctiveness Conflict Risk	The closed-loop test-debugging niche with re-run iteration is mostly distinct, with only minor overlap risk against closely related skills like test-runner or build-fixer that the body itself references.	4 / 5
	Total	15 / 20 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: CharlesWiltgen/Axiom
Path: axiom-codex/skills/axiom-debug-tests/SKILL.md
Commit: 69ffef6

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.