test-auto-fix

Solid

Diagnoses failing tests across any project, classifies each failure as a test-bug, prod-bug, or unsure, confidence-gates the fix (auto-apply at >=90%, 80-89 ask, <80 escalate), applies it, and re-runs until green. Surface-driven: reads per-project configuration from a surface file keyed by normalised git remote URL. Bootstrap auto-detects the stack on first run and proposes a surface diff for user approval. Hard-refuses to delete tests, add .skip/.only, or weaken assertions. Regression-detects after every fix: reverts on new failure instead of stacking. Triggers on "fix my failing tests", "tests are red", "auto-fix tests", "heal the tests", "/test-auto-fix".

Testing & QA 8 stars 2 forks Updated 2 days ago MIT

Install

View on GitHub

Quality Score: 84/100

Stars 20%
32
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# test-auto-fix Autonomously diagnose and fix failing tests in any project, with hard guardrails so the loop never devolves into "make the red go away". This `SKILL.md` is the **orchestration index**. Load the matching rule file when you need detail — do not preload them. | Phase | Goal | Required rule | | ----- | ---- | ------------- | | 0 | Resolve the surface (bootstrap or validate) | [`rules/bootstrap.md`](./rules/bootstrap.md) + [`rules/surface-validation.md`](./rules/surface-validation.md) | | 1 | Detect which test surface(s) are failing; build fix plan | this file + [`templates/plan-artifact.md`](./templates/plan-artifact.md) | | 2 | Per failure: classify as test-bug / prod-bug / unsure | [`rules/verdicts.md`](./rules/verdicts.md) + [`rules/self-improvement-loop.md`](./rules/self-improvement-loop.md) (read lessons) | | 3 | Per failure: draft the smallest possible fix | this file | | 3.5 | Confidence gate — before any edit | [`rules/confidence-gate.md`](./rules/confidence-gate.md) | | 4 | Apply + verify single failing test | this file + [`rules/anti-patterns.md`](./rules/anti-patterns.md) | | 5 | test-provenance-guard (optional companion) | invoke `Skill("test-provenance-guard")` | | 6 | Outer loop: re-run full surface; regression-detect | [`rules/regression-detection.md`](./rules/regression-detection.md) + [`rules/self-improvement-loop.md`](./rules/self-improvement-loop.md) (write lessons) | | 7 | Report (structured exit summary) | [`templates/exit-summary.md`](./te...

Details

Author
mthines
Repository
mthines/agent-skills
Created
3 months ago
Last Updated
2 days ago
Language
TypeScript
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Solid

ci-auto-fix

Diagnoses a failed CI check, classifies it with an explicit verdict (code-bug | workflow-bug | dep-bug | env-bug | flaky | unsure), confidence-gates the fix (>=90 auto, 80-89 ask, <80 escalate), applies it, pushes, and iteratively verifies until CI passes — reverting the last commit if a brand-new failure appears. Provider-agnostic in scope; currently implements the GitHub Actions path via `gh`. Hard- refuses to disable, skip, or weaken checks. Triggers on "CI is failing", "fix the CI", "the build is red", "auto-fix this PR's checks", "GitHub Actions failed", "/ci-auto-fix".

8 Updated 2 days ago
mthines
AI & Automation Listed

fix-test

Auto-diagnose and fix failing tests — up to 3 attempts with re-runs. Triggers on: fix test, failing test, broken test, test error, why is this test failing, debug test.

10 Updated today
Smart-AI-Memory
Testing & QA Listed

tests

Fixes failing tests and lint/type errors, audits test-suite quality with a fleet of specialist reviewers, or drives coverage — for any project configured with a supermodo skills.config.json. Modes: `tests` (default) fixes every failure tier by tier (unit, integration, E2E, lint); `tests audit [scope]` spawns parallel specialist reviewers (spec-alignment, assertion-strength, corner-cases, coverage-balance, and a domain lens derived from the project's docs), runs mutation probes where configured, and adversarially verifies every finding with a second model before reporting; `tests coverage` drives coverage to the configured target with a balance check. Use whenever the user mentions failing tests, lint errors, "make tests pass", green build, flaky tests, test quality, weak or missing tests, corner cases, coverage, mutation testing, or asks whether the tests actually protect the core logic — even without "/tests".

0 Updated 2 weeks ago
supermodo