df-implement-review

Review code changes and implementations against four correctness questions before commit or merge.

3|1|Updated Feb 26, 2026
One-click install
npx skills add https://github.com/wopal-cn/wopal-space-ontology --skill df-implement-review-wopal-cn
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: df-implement-review
Source: https://github.com/wopal-cn/wopal-space-ontology/tree/main/skills/df-implement-review
Command: npx skills add https://github.com/wopal-cn/wopal-space-ontology --skill df-implement-review-wopal-cn

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Code that passes tests, lint, and CI can still ship stubs, silently break existing callers, contain concurrency or security defects, or rest on fake test evidence. This Skill provides a disciplined review method that catches exactly the failures mechanical gates miss, before a change is committed or merged. ## Core Features & Use Cases - Four-question review framework: verifies the change delivers what it claims (stub and wiring detection), does not break existing consumers (contract-surface analysis), is correct under real inputs (defect catalogue covering concurrency, resources, boundaries, async, errors, security), and is backed by honest test evidence with no hidden debt. - Plan-backed and planless modes: reviews against explicit Plan truths and design constraints when available, or against the change's own stated intent for bare diffs, commits, and commit ranges. - Structured verdicts and reports: emits PASS / REVISE / BLOCK verdicts with Blocker, Warning, and Info findings, each citing file, line, evidence, impact, and fix direction, plus a detailed rubric with probe commands and worked examples. - Use Case: Before merging a pull request, ask for a review of the working tree changes; the Skill reads the diff once, probes consumers of every changed symbol with ripgrep, and returns a report flagging a stubbed API handler as a Blocker and an undocumented contract change as a Warning. ## Quick Start Ask the assistant to review the current working tree changes or a specific commit using the df-implement-review skill before you commit or merge.

Frequently Asked Questions about df-implement-review

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

FAQPage Schema
How do I review a pull request or code change with this skill?

Point the review at a working tree, commit hash, or commit range, optionally with a Plan path for acceptance criteria. The skill reads the diff once, builds claim, contract, and suspicion lists, then probes with targeted ripgrep commands and returns a verdict report.

What does an implementation review check beyond tests and lint?

It checks four things mechanical gates miss: whether claimed behavior is real and wired in, whether existing callers break from silent semantic changes, whether new code fails under real inputs like concurrency or boundary conditions, and whether tests genuinely prove what they claim.

When should I use df-implement-review versus df-plan-review?

Use df-implement-review for finished code changes, commits, and pull requests. Use df-plan-review when reviewing a Plan or design before implementation begins. The implementation review never re-runs tests, builds, or fixes code.

Can the review run without a plan or acceptance criteria?

Yes. In planless mode it uses the change's own stated intent, such as the description or commit message, as the specification. It will not invent product requirements; ambiguities go into a Requirement Questions section of the report.

What do the PASS, REVISE, and BLOCK verdicts mean?

PASS means no Blockers and no Warnings, REVISE means at least one Warning but no Blockers, and BLOCK means at least one Blocker. A PASS still requires Positive Findings describing what was verified, and no verdict authorizes merging by itself.

How many times can the same change be re-reviewed?

At most twice: one exhaustive initial review plus one re-review that verifies fixes and re-sweeps everything. The re-review report is final, so the first review must report every finding including borderline ones.