recheck-v2

Verifies recorded build fixes with a fresh closed-checklist verifier and moves slice status cards.

Updated Jun 2, 2026
One-click install
npx skills add https://github.com/line7works/tony-skills --skill recheck-v2-line7works
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: recheck-v2
Source: https://github.com/line7works/tony-skills/tree/main/plugins/recheck-v2/skills/recheck-v2
Command: npx skills add https://github.com/line7works/tony-skills --skill recheck-v2-line7works

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires jsonschema, and includes scripts (resource) and references (resource) components.

What problem does it solve? After a code review rejects a slice with BLOCKER or MAJOR findings, someone must prove each named fix actually landed before the slice's status card can move. Recheck-v2 closes that gap with a closed-checklist re-inspection: a fresh, independent verifier checks only the recorded findings, and every disposition is evidence-backed and receipted. ## Core Features & Use Cases - Closed-checklist verification: Scope is limited to the open BLOCKER and MAJOR entries in a build doc's punch list plus user-named items; the list only shrinks, never grows through open-ended hunting. - Independent fresh-context verifier: A new verifier (subagent, codex exec run, or OpenCode session) receives only the checklist brief, never the fixer's account, and reports per-item dispositions with evidence. - Transactional, receipted recording: All writes (reopening lines, punch-list block, waivers, status lines) happen in one write-ahead-receipted transaction with source-identity checks and boundary-violation detection. - Use Case: After fixing the majors from a signoff review of Slice A, ask for a recheck; the skill verifies each fix against its failure scenario, records dispositions, and flips the slice's card from rejected to signed off when everything clears. ## Quick Start Ask the assistant to recheck slice A of your build doc and flip the card if the named fixes landed.

Frequently Asked Questions about recheck-v2

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

FAQPage Schema
How do I verify that code review findings were actually fixed?

Run a closed-checklist recheck: name the build doc and slice, and a fresh verifier checks each recorded BLOCKER or MAJOR finding against its failure scenario. Each item gets a fixed or not_fixed disposition with evidence, and the slice's status card moves only when the open set clears.

What is the difference between a recheck and an initial code review?

A recheck only verifies named, recorded findings from a prior review; the checklist only shrinks and no new hunting happens. Initial review, open-ended defect hunting, and repair are separate jobs handled by other stations like signoff or inspect.

Which AI harnesses does recheck-v2 support?

Adapter profiles exist for Claude Code, Codex CLI, and OpenCode, each providing invocation helpers and a fresh-context verifier capability. A harness without an adapter profile stops the run as verifier_unavailable and grades nothing.

Can the same session that wrote the fix verify it?

No. The verifier must be a fresh context that never wrote the fix, and the driving session's session_wrote_fix flag is recorded. An upgrade of a not_fixed item by a session that authored the fix is recorded as disputed and the item stays open.

What happens if the source code changes during a recheck run?

The run computes a git source identity at start and again before recording; a mismatch stops the run as stale_source with nothing written. Retained verifier reports are also re-hashed before the transaction, and a changed report stops the run.

When should I not use recheck-v2?

Do not use it for initial reviews, whole-build capstone reviews, plan checks, or re-running tests for the fixer. It also refuses findings nobody recorded and workspaces with initialized git submodules.