change-set-verification

Verifies a completed change set against owner-supported checks before handoff.

Updated May 19, 2026
One-click install
npx skills add https://github.com/wenyue/SmartKit --skill change-set-verification-wenyue
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: change-set-verification
Source: https://github.com/wenyue/SmartKit/tree/main/setup-assets/blueprints/skills/change-set-verification
Command: npx skills add https://github.com/wenyue/SmartKit --skill change-set-verification-wenyue

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Before handing off a completed implementation checkpoint, teams need objective evidence that the change set actually works. This Skill defines a verification contract that runs the minimum sufficient formatter, static, test, build, and diff-integrity checks, then returns an evidence-backed verdict instead of an unverified claim of completion. ## Core Features & Use Cases - Scoped verification contract: Establishes the complete change and comparison point from accepted task context and Git state, then selects only owner-supported verification surfaces. - Ordered evidence pipeline: Runs normalization first, then non-mutating static checks, directly owned tests, and broader surfaces justified by risk, with each surface reported as passed, failed, inconclusive, or not applicable. - Deterministic verdicts: Returns exactly one of semantic_fix_required, failed, inconclusive, or passed based on trustworthy evidence, while preserving HEAD, the index, and user-owned files. - Use Case: After an agent finishes implementing a feature in a repository, invoke this Skill to verify the checkpoint with the project's own formatter, linters, and tests, and receive a passed verdict or precise diagnostics routed back to the implementation owner. ## Quick Start Ask the agent to verify the current completed change set in this repository using its change-set-verification Skill and report the verdict with evidence.

Frequently Asked Questions about change-set-verification

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

FAQPage Schema
How do I verify a completed code change before handoff?▼

Run the change-set-verification Skill on the completed checkpoint. It establishes the change scope from Git state, applies the owner-supported formatter, then runs static checks and directly owned tests, returning a single evidence-backed verdict.

What verdicts does change set verification return?▼

It returns exactly one of four results: semantic_fix_required when evidence shows the implementation owner must change semantics, failed for proven mechanism or tool failures, inconclusive when required evidence is insufficient, or passed when all required surfaces pass.

Does the verification Skill modify my repository files?▼

Only within a strict grant: owner-supported formatting and authorized automatic fixes on selected project-owned sources. It preserves HEAD, the index, unrelated work, and user-owned files, and reports every mutation it makes.

When does verification return inconclusive instead of failed?▼

It returns inconclusive when required evidence, ownership, prerequisites, comparison point, or baseline classification is insufficient, such as missing authority for a required effect. Failed requires trustworthy evidence of an actual mechanism or tool failure.

Can verification checks run concurrently?▼

Independent non-mutating checks may run concurrently when the harness preserves selectors and evidence. Mutation-sensitive checks and generated-output consumers keep their dependency order to keep evidence trustworthy.