bug-fix-verification

Verifies review-reported bugs against actual code and syncs fix status to SQLite tracking tables.

10|3|Updated Mar 7, 2026
One-click install
npx skills add https://github.com/Cynthia1070711/PHYCOOL_Tools --skill bug-fix-verification-cynthia1070711
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: bug-fix-verification
Source: https://github.com/Cynthia1070711/PHYCOOL_Tools/tree/main/config-templates/claude/skills/bug-fix-verification
Command: npx skills add https://github.com/Cynthia1070711/PHYCOOL_Tools --skill bug-fix-verification-cynthia1070711

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires better-sqlite3.

What problem does it solve? Code review reports list bugs, but a Story marked done does not prove the bugs were actually fixed. This Skill closes that gap by reading the real source code for each finding, judging whether it is FIXED, PARTIAL, OPEN, NOT_APPLICABLE, or FALSE_POSITIVE, and persisting the verdict into the review_findings and tech_debt_items database tables so nothing falls through before the Production Gate. ## Core Features & Use Cases - Code-level fix verification: Reads the affected file at the reported line number and compares it against the bug's root cause before marking anything fixed, with file:line evidence recorded. - Bug query and search modes: Full-text search (FTS5), per-file bug lookup, per-module overview, and severity/status statistics across the review_findings table. - Status synchronization: Writes FIXED results to review_findings and syncs DEFERRED bugs into tech_debt_items with severity mapping (P0→critical, P1→high, etc.). - Use Case: Before a code-review Production Gate, run verification for a Story, confirm all P0/P1 bugs are fixed with code evidence, defer the rest into tech debt, and block the gate if any critical bug remains open. ## Quick Start Ask the AI to verify whether all bugs assigned to story X are actually fixed in the code and update the review findings database with the results.

Frequently Asked Questions about bug-fix-verification

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify that code review bugs are actually fixed?

Query the review_findings table for bugs linked to the Story, then read each affected file at the reported line number and compare the code against the bug's root cause. Mark each finding FIXED with file:line evidence, or OPEN, PARTIAL, NOT_APPLICABLE, or FALSE_POSITIVE as appropriate.

How to search known bugs by keyword or file path in SQLite?

Use the review-db-writer.js CLI with --query-findings for module queries, or run a read-only better-sqlite3 query filtering file_path with LIKE for per-file checks. The review_findings_fts FTS5 index supports trigram full-text search over title, description, and file path.

Can a Story be marked done while review bugs are still open?

No. Story done does not equal bug fixed. Open P0 or P1 bugs must block progression to review and the Production Gate until they are verified fixed in code or explicitly deferred into tech_debt_items.

What happens to bugs that are deferred instead of fixed?

Deferred bugs are updated in review_findings with fix_status deferred and a target Story, then synced into tech_debt_items via upsert-debt.js with severity mapped from P0 to critical down to P4 to low, keeping them tracked as pending debt.

Why must bug status updates go through the review-db-writer CLI?

Direct SQLite writes are forbidden because the CLI enforces schema rules and automatically sets fields like fixed_at when fix_status becomes fixed. This keeps the 939-finding database consistent and auditable.