Skip to content
Back to skills

Debugging

ASecurity

Use when tests are failing, when investigating flaky or persistent failures, or when a failure signature needs systematic diagnosis through vitest-agent's test_history, test_errors, and failure_signature_get surfaces.

  • 2 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added November 7, 2026
testingbashdebuggingapidatabase

Works with

  • api
  • mcp

Security analysis

A100/100

Scanned November 7, 2026

npx -y skills add spencerbeggs/vitest-agent --skill debugging --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Debugging?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Debugging
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/spencerbeggs-debugging/badge)](https://www.skillsdirectory.com/skills/spencerbeggs-debugging)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: debugging
description: Use when tests are failing, when investigating flaky or persistent failures, or when a failure signature needs systematic diagnosis through vitest-agent's test_history, test_errors, and failure_signature_get surfaces.
---

# Debugging Test Failures

Systematic approach to diagnosing and fixing test failures using
MCP tools.

## Step 1: Classify the Failure

Use `test_history` to understand the failure pattern:

- **New failure:** First time this test failed. Likely caused by
  a recent change
- **Persistent failure:** Failed multiple runs in a row. Likely a
  real bug or environment issue
- **Flaky test:** Intermittent pass/fail. Could be timing,
  ordering, or shared state

## Step 2: Examine the Error

Use `test_errors` to search for the specific error:

- Search by error name to find similar failures across tests
- Check if the same error appears in other projects
- Look at the diff (expected vs received) for assertion failures

## Step 3: Find Related Tests

Use `test (action: for_file)` to find all tests that cover the file
containing the failure. This helps you:

- Understand the test surface for the affected code
- Find tests that might be affected by the same bug
- Identify missing test coverage

## Step 4: Check Coverage Context

Use `test_coverage` to see:

- Which lines in the failing file are uncovered
- Whether the failure is in a well-tested or poorly-tested area
- Coverage trends (is coverage improving or degrading?)

## Step 5: Document Findings

Use `note (action: create)` to record:

- Root cause analysis
- Steps to reproduce
- Fix strategy
- Any workarounds applied

Pin important notes with `note (action: update)` so they persist across
sessions.

## Step 6: Verify the Fix

1. Run the specific failing test:
   `run_tests({ files: ["path/to/failing.test.ts"] })`
2. Run the full suite to check for regressions: `run_tests({})`
3. Check `test_trends` to confirm coverage direction

Always use the `run_tests` MCP tool instead of running vitest via
Bash. It uses Vitest's programmatic API, so results persist to the
database and all query tools reflect the latest run immediately.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.