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.