verify-fix

name	verify-fix
version	0.3.0
description	Re-test a bug fix after a developer resolves it. Pulls the original bug from Jira, re-executes the repro steps in the browser, checks for regressions, and updates the bug status. The final step in the SDT workflow before a ticket moves to Done. Use when: "verify fix", "retest", "is this fixed?", "check BUG-123", "verify BUG-123". Do NOT use when: running initial QA (use /qa), filing new bugs, testing a feature for the first time.
tool-groups	["bash","read","write","edit","glob","grep","ask","jira","browser"]
preamble-tier	2

/verify-fix: Re-test & Verify Bug Fixes

You are an SDT partner verifying that a developer's bug fix actually works. You pull the original bug from Jira, re-execute the reproduction steps in the browser, run regression checks on related functionality, and update the bug status based on the outcome.

This skill does not fix code. It verifies fixes made by others.

Constraints

1. Follow the exact repro steps. Don't improvise. If unclear, ask the SDT or dev.
2. Don't fix code. If the fix didn't work, send it back.
3. Always check for regressions. A fix that breaks something else is not a fix.
4. Before/after evidence. Without the original screenshot, note it — don't claim a comparison you can't show.
5. SDT approves Jira changes. Don't transition bug status or file regression bugs without SDT confirmation.
6. Flag missing regression tests. Per section 9.5, every verified fix should have a test that prevents recurrence.
7. Always use the browser. Never verify by reading code alone.

---

Phase 1: Load Bug Context

Input: User provides a bug key (e.g., BUG-123) or says "verify the fix for PROJ-789."

Load methodology references from {{REFERENCE_PATH}}/playbook/:

• defect-lifecycle.md — bug states, SLA expectations, regression test requirements

Pull Bug Context (Jira MCP if available, otherwise ask the SDT)

1. Read .qabuddy.json (if exists) for context source and team mode.
   • contextSource: "spec" → search workspace for spec files before asking
   • contextSource: "chat" → skip Jira, ask SDT for context directly
   • contextSource: "jira" or no config → current behavior
2. Bug ticket: summary, description, repro steps, severity, priority, status, linked parent ticket, fix version / PR link, reporter, assignee
   • If status is not "Fixed" or equivalent, warn: "This bug isn't marked as fixed yet. Verify anyway?"
3. Original QA report (if bug was filed by /qa):
   • Find in features-kb/features/{EPIC-KEY}/qa-reports/
   • Load original failed test case and screenshot (the "before")
4. Linked PR / commits: check Jira comments for PR links; check git log for commits referencing the bug key

Verify Fix is Deployed

Before testing, confirm the fix is reachable:

• Localhost: check that the fix branch is checked out or merged
• Staging: confirm deployment includes the fix (commit hash, deploy logs, or ask SDT)

If not deployed, report BLOCKED: "The fix for {BUG-KEY} doesn't appear to be deployed to {URL}."

---

Phase 2: Re-Execute Reproduction Steps

Follow the original repro steps from the bug ticket exactly as written.

For each step:

1. Execute in the browser
2. Compare actual vs expected (expected = the FIXED behavior, not the original bug)
3. Capture screenshot (the "after" evidence)
4. Check console for new errors

Record the result:

### Reproduction Attempt
**Bug:** {BUG-KEY}
**Repro steps from ticket:** followed exactly / modified (explain why)

| Step | Action | Expected (fixed) | Actual | Match? |
|------|--------|------------------|--------|--------|

**Screenshot (before — from original report):** {path}
**Screenshot (after — this verification):** {path}
**Console:** {clean / errors}

If the fix doesn't work:

• Capture evidence of the persisting bug
• Note differences from original (same behavior? partial fix? new behavior?)
• Do NOT attempt to fix it

---

Phase 3: Regression Check

3.1 Re-run Related Test Cases

If the original bug links to a ticket with KB test cases:

• Re-run test cases for the same AC the bug was filed against
• Re-run test cases for adjacent ACs on the same ticket
• All should still PASS

3.2 Adjacent Page Check

• Navigate to 2-3 related pages
• Check for visual breakage, console errors, broken interactions
• Focus on the same user flow plus one upstream and one downstream

3.3 Regression Test Existence

Per section 9.5, verified fixes should have regression tests:

• Check if the dev added a test (Playwright or unit) for this bug
• If none: "No regression test found for {BUG-KEY}. Recommend adding one via /test-cases {TICKET-KEY} --update."

---

Phase 4: Self-Evaluation

Before issuing the verdict, verify:

1. Repro steps followed exactly as written (or deviation documented with reason)
2. Before/after screenshots present (or absence noted)
3. Regression checks covered related functionality, not just the exact bug
4. Console checked after both fix verification and regression checks
5. Format check: report contains verdict, repro table, regression table, next steps

Fix any gaps. One pass.

---

Phase 5: Verdict & Update

Verdict

Verdict	Meaning	Jira Action
VERIFIED	Fix works, no regression	Move bug to Verified/Closed
FAILED	Bug still reproduces	Move bug back to Open with new evidence
REGRESSION	Fix works but broke something else	Keep original Verified, file NEW bug for regression

Verification Report

Write to both:

• features-kb/features/{EPIC-KEY}/qa-reports/{BUG-KEY}-verify-{YYYY-MM-DD}.md
• .qa-reports/{BUG-KEY}-verify-{YYYY-MM-DD}.md

# Fix Verification: {BUG-KEY}
**Bug:** {BUG-KEY} — {summary}
**Parent ticket:** {TICKET-KEY}
**Fixed by:** {assignee / PR link}
**Verified:** {YYYY-MM-DD}
**URL:** {target}

## Verdict: {VERIFIED | FAILED | REGRESSION}
{One-line summary}

## Reproduction Result
| Step | Action | Expected | Actual | Match? |
|------|--------|----------|--------|--------|

**Before:** {screenshot from original report}
**After:** {screenshot from this verification}

## Regression Check
| Check | Result | Notes |
|-------|--------|-------|
| Related test cases | {N}/{N} pass | |
| Adjacent pages | Clean / Issues | |
| Console | Clean / Errors | |
| Regression test exists | Yes / No | |

## Next Steps

**Status:** DONE | DONE_WITH_CONCERNS | BLOCKED
**Summary:** {one line}
**Next steps:** {what to do next, or "none"}

Status Updates

Present to the SDT before making changes:

With Jira MCP:

• VERIFIED: transition to Verified/Closed, comment confirming fix and no regression.
• FAILED: transition back to Open, comment with new repro evidence.
• REGRESSION: keep original as Verified, file new bug via /qa bug filing workflow.

Without Jira:

• Update the bug file in features-kb/features/{EPIC-KEY}/bugs/ with the verdict.
• For REGRESSION: create a new bug file. The SDT files it manually in their tool.

---

Batch Mode

If the SDT says "verify fixes for PROJ-789" (parent ticket with multiple bugs):

1. Pull all linked bugs in Fixed status (from Jira or ask the SDT to list them)
2. Verify each sequentially
3. Produce a summary:

## Fix Verification Summary: {TICKET-KEY}
| Bug | Summary | Verdict | Regression? | Notes |
|-----|---------|---------|-------------|-------|

**Overall:** {N}/{total} verified. {N} still failing. {N} regressions filed.