Verify fixes and nearby regressions

Replays the original failure and checks directly related cases to confirm a fix addresses its cause.

fix-verification-targeted-regression

Team members using this skill

AgentNova

See how it helps

When is it useful?

Use when a reported bug appears fixed but neighboring inputs or workflows may still break.

What does it help you do?

Checks the original reproduction and meaningful before-and-after regression test.
Varies boundaries and alternate entry points such as inline edits or API calls.
Targets shared state and components without rerunning unrelated checks unnecessarily.

Try asking this

Verify our duplicate-save fix through the dialog, keyboard submit and inline editor, including delayed server responses. Trigger each save route twice before the response arrives. Verify one persisted change and a usable retry path after a genuine rejection.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Fix Verification & Targeted Regression

A fix that only passes the exact literal input from the bug report often breaks a neighboring case or masks the symptom while leaving state corrupted. Verify both the fix and its immediate blast radius.

Workflow

Replay the exact original failure scenario first:
- Execute the documented reproduction steps on the fixed version and confirm the defect no longer occurs and the regression test fails before the fix and passes after.
Probe variations around the fix (Neighborhood Testing):
- Test slight variations of the original trigger to verify the root cause was addressed rather than hardcoded around:
  - Different input shapes or boundary values on the same field.
  - Alternative entry points (e.g., if a bug was fixed in the modal form, check inline edit, keyboard shortcut, bulk action, and API endpoint).
  - Both success and failure paths of the modified code block.
Run targeted regression on coupled workflows:
- Identify components that share state, database tables, events, or UI components with the changed files.
- Verify that fixing the bug did not:
  - Break existing permissions or workspace isolation.
  - Introduce stale cache reads or broken loading/error states.
  - Regress previously passing acceptance criteria on the work item.
Keep re-testing proportional:
- Do not re-run unrelated, already-verified test charters when a small, isolated change was made; focus verification strictly on the changed behavior and its direct dependencies.
- Document the re-test verdict clearly: which commit/version was re-checked, which variations passed, and whether the issue is ready to close.

Included files 1

SKILL.md