How to use the AI Regression Testing agent skill

What does the skill make the agent do?

The skill is built on one observation: when the same model writes a fix and then reviews it, it tends to repeat the same blind spots. The source gives an example where an API response gained a new field, the SELECT query that fetched it was not updated, and the AI review missed the gap. The skill's answer is to rely on automated tests and builds to catch these problems first, then run AI review.

• Write database-free API tests that run against a sandbox or mock mode.
• Run the test suite and a build before any AI code review, and report failures as the highest-priority bugs.
• Add a regression test for each bug that gets fixed, so the same bug is caught if it returns.
• Watch for common patterns, especially a mismatch between sandbox and production code paths.

How do you install the ai-regression-testing skill?

Download the ZIP for this skill from the page, then use one of the two options below. The skill package contains a single file, SKILL.md.

Option A: unzip it into your personal skills folder at ~/.claude/skills/, or into a project's .claude/skills/ folder to make it available only in that project.

Option B: in the Claude apps, open Settings, go to Capabilities, and upload the skill under Skills.

How do you trigger the skill with a natural request?

You do not need a special command to start the skill. The source lists situations where it applies: the agent has just changed an API route or backend logic, a bug was found and fixed and must not return, the project has a sandbox or mock mode, you are about to run a bug check after changes, or the code has several paths such as sandbox versus production or feature flags.

The source also describes a bug-check command, /bug-check, which is defined in your project as a markdown file at .claude/commands/bug-check.md. If you create that file, you can type /bug-check or ask in plain words to run a bug check.

• "Fix the profile endpoint and make sure the tests cover it."
• "I found a bug in the messages API. Fix it and add a regression test."
• "Run a bug check on my recent changes."
• "Check that the sandbox and production responses for this route have the same fields."

What does the bug-check routine look like?

The source's example command file runs automated checks first and only moves to AI review if both pass. Its order is: run the tests, run the build, do the AI code review, then write a regression test for each fix. Failing tests and type errors are reported as top priority because they can be verified without judgement.

• Step 1: run the test suite, which is required and cannot be skipped.
• Step 2: run the build, which includes TypeScript type checking.
• Step 3: AI code review, checking sandbox and production consistency, response shape, SELECT completeness, error handling with rollback, and race conditions in optimistic updates.
• Step 4: propose a regression test for each fixed bug.

How do you set up sandbox-mode API tests?

The examples assume Vitest with a Next.js App Router project. The Vitest config includes test files from __tests__/**/*.test.ts and a setup file that forces sandbox mode on, so tests run without a database. A helper builds Next.js requests with an optional x-sandbox-user-id header and parses the JSON response.

Write each regression test for the bug you found, not for code that already works. The source's profile example defines the required fields as a contract and adds a dedicated test for a field that was previously missing.

• Set SANDBOX_MODE to true in the test setup file.
• Clear the Supabase URL and anon key variables so no real database is reached.
• Keep a list of required response fields per endpoint and assert each one exists.
• Add a test for each bug, and name it after the bug so its purpose is clear.

Which common regressions should the tests catch?

The source lists four recurring patterns. The most common is a sandbox and production path that return different shapes: a field is added to the production return but not to the sandbox return, or the reverse. The source also covers a Supabase or Prisma SELECT that omits a newly added column, error handling that leaves stale data on screen, and optimistic updates that do not roll back when the request fails.

For the sandbox mismatch, the source suggests a test that checks the sandbox response contains every required field.

• Sandbox and production paths returning different fields (the most common, seen in three of four regressions in the source).
• A SELECT clause that leaves out a new column, so the field is always undefined.
• Error states that show old data after a failed load; clear related state in the catch block.
• Optimistic UI updates with no rollback when the API call fails.

What do you need before using it?

The skill assumes a working JavaScript or TypeScript project. The source lists Node.js and npm, the Vitest test framework for the examples, TypeScript build tooling, and an existing sandbox or mock mode for the sandbox examples. Without a sandbox mode, the database-free tests in the guide do not apply, though the bug-check routine and regression-test advice still do.

The skill runs no scripts and makes no network requests itself. Any commands it suggests, such as npm run test, run in your own project on your machine.

• Node.js and npm installed.
• Vitest configured in the project (the examples use it).
• TypeScript build set up so npm run build performs type checking.
• A sandbox or mock mode if you want the database-free API tests.