sb-review-task

Reviews one implemented task against its diff, requirements, and design to return a verdict.

Updated Jul 17, 2026
One-click install
npx skills add https://github.com/Huruikagi/pc-build-planner --skill sb-review-task-huruikagi
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: sb-review-task
Source: https://github.com/Huruikagi/pc-build-planner/tree/main/.agents/skills/sb-review-task
Command: npx skills add https://github.com/Huruikagi/pc-build-planner --skill sb-review-task-huruikagi

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Implemented tasks often get approved based on the implementer's summary rather than the actual change, letting unmet requirements and weakened tests slip through. This Skill performs an independent, read-only review of a single task by comparing the real git diff against the approved requirements, design documents, and steering inputs. ## Core Features & Use Cases - Diff-first review: Reads git status and git diff before any report, treating implementer summaries as claims to verify rather than truth. - Governed input loading: Pulls the task definition, requirements, contract, split designs, implementation notes, and steering documents through specbind commands so the verdict is grounded in approved inputs. - Structured verdicts: Returns APPROVED, REJECTED, or CANNOT_REVIEW with dispositioned findings (BLOCKING, DEFERRED, RESOLVED), and records deferred findings only through the project's configured adapter. - Use Case: After a developer finishes a task in a spec-driven workflow, invoke this Skill to independently confirm the diff satisfies the stated requirements before the task is marked complete. ## Quick Start Ask the assistant to use sb-review-task to review the pending task for the current spec and return its verdict with findings.

Frequently Asked Questions about sb-review-task

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

FAQPage Schema
How do I review an implemented task against its requirements?▼

Invoke the review with an explicit spec and task ID, or let it resolve the single pending actionable task via specbind milestone and task listing. It reads the git diff first, then the requirements, designs, and steering, and returns a verdict with findings.

What verdicts can a task review return?▼

The review returns APPROVED, REJECTED, or CANNOT_REVIEW. Every finding carries a disposition of BLOCKING, DEFERRED, or RESOLVED, and every rejection names what would make the change approvable.

Can the review fix issues it finds in the code?▼

No. The review is strictly read-only and never modifies the implementation, runs gate commands, or writes implementation notes. The only permitted write is recording a deferred finding through the project's configured adapter after the verdict is final.

What happens when the review cannot determine which task to review?▼

If zero or multiple pending tasks exist, it lists the candidate spec and task IDs and asks the user to choose. If the working tree contains changes the task does not own, it returns CANNOT_REVIEW rather than guessing which hunks belong to the subject.

Does the task review handle weakened or deleted tests?▼

Yes. A deleted assertion, loosened tolerance, or skipped test is treated as a rejection unless the change genuinely made that check obsolete and says so. Weakened verification ranks alongside wrong behavior as a blocking finding.