semi-formal-review

Reviews implemented code changes with a semi-formal certificate producing a derived correctness verdict.

Updated May 4, 2026
One-click install
npx skills add https://github.com/antstanley/skills --skill semi-formal-review-antstanley
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: semi-formal-review
Source: https://github.com/antstanley/skills/tree/main/plugins/spec-builder/skills/semi-formal-review
Command: npx skills add https://github.com/antstanley/skills --skill semi-formal-review-antstanley

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Code reviews often degrade into opinion-based vibe checks that miss name shadowing, scope ambiguity, and regressions. This Skill turns post-implementation review into a structured certificate — premises, claims, evidence, and a verdict derived from explicit checkpoints — so correctness decisions are defensible rather than asserted. ## Core Features & Use Cases - Certificate-based review: Runs a fixed 6-step procedure (premises, function resolution, execution trace, regression check, edge cases, verdict) on every diff, producing a CORRECT / LIKELY_CORRECT / CONCERNS / BUGGY verdict with confidence and summary. - Spec-builder correctness gate: Acts as the mandatory correctness gate after a spec-builder task is implemented, run by an agent other than the one that wrote the code, complementing the validate-done-certificate completeness gate. - Skip conditions for trivial changes: Recognizes docs, formatting, and version-bump changes and records the gate as skipped rather than fabricating ceremony. - Use Case: A spec-builder sub-agent finishes implementing a passphrase-lock task; the orchestrator dispatches this Skill against the workspace diff, which resolves each call through the 5-step sequence, flags a shadowed verify() function, traces a concrete input, checks a downstream caller, and returns VERDICT: BUGGY with the offending line. ## Quick Start Ask the agent to run a semi-formal review of the diff produced by the just-completed task before marking it done.

Frequently Asked Questions about semi-formal-review

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

FAQPage Schema
How do I review a code diff for correctness before merging?▼

Run a semi-formal review on the diff: state premises about what changed and what was asked, resolve every call through the 5-step function-resolution sequence, trace one concrete input, check a downstream caller for regressions, then derive a CORRECT, LIKELY_CORRECT, CONCERNS, or BUGGY verdict from those checkpoints.

What is a semi-formal certificate in code review?▼

A semi-formal certificate is a structured natural-language review artifact with premises, claims, evidence, and a conclusion derived from explicit checkpoints. It stays in natural language rather than a proof language, but its structure bars skipped cases and unsupported claims.

How does semi-formal-review differ from validate-done-certificate?▼

semi-formal-review gates correctness — whether the implementation is right and free of shadowing bugs and regressions — while validate-done-certificate gates completeness against the task's definition of done. Both reuse the same procedure from references/method.md against different verdict rubrics.

Can the same agent that wrote the code run the review?▼

No. The reviewer must differ from the builder, because an agent reviewing its own work re-asserts its own assumptions. In spec-builder the implementer is a sub-agent and the review runs from the orchestrator or a separate reviewer sub-agent.

When should I skip a semi-formal review?▼

Skip the full certificate for trivial changes such as docs, formatting, version bumps, or locally obvious fixes with no execution path crossing a scope boundary. In a spec-builder build, record that the gate was skipped as trivial rather than bypassing it silently.

Why does the review flag name shadowing in diffs?▼

Name shadowing is the classic confidently-wrong bug: a call may resolve to a module-level or local definition instead of the intended import or builtin. The 5-step resolution sequence checks local, class, module, import, and builtin scopes in order and flags any shadowing that could change behavior.