common-verification-first

Enforces verification-first engineering policies for planning, implementing, and reviewing repository changes.

138|5|Updated Sep 19, 2024
One-click install
npx skills add https://github.com/macalbert/envilder --skill common-verification-first-macalbert
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: common-verification-first
Source: https://github.com/macalbert/envilder/tree/main/.github/skills/common-verification-first
Command: npx skills add https://github.com/macalbert/envilder --skill common-verification-first-macalbert

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often let implementations define their own success criteria, leading to tests that merely mirror the code written and reviews that rubber-stamp changes. This Skill establishes a normative verification-first policy so expected behavior is defined independently before any solution is built. ## Core Features & Use Cases - Intent Classification: Categorizes every change as NEW_BEHAVIOR, BEHAVIOR_CHANGE, BUG_FIX, PURE_REFACTOR, or NON_BEHAVIORAL_CHANGE, each with its own verification rules. - Role Separation: Defines distinct ownership for Change Orchestrator, Verifier, Implementer, and Reviewer so verification contracts stay independent from solution artifacts. - Structured Result Envelopes: Provides canonical shapes like VerificationContract, ImplementationResult, ReviewResult, and FinalVerificationResult for consistent handoffs. - Use Case: When fixing a bug in a CLI tool, the policy requires reproducing the defect with a focused regression test before the fix, then running a fresh final verification against the original approved requirement. ## Quick Start Apply the verification-first policy to plan and verify my next bug fix, starting by classifying the intent and establishing a verification contract before any code changes.

Frequently Asked Questions about common-verification-first

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

FAQPage Schema
How do I apply verification-first workflow to a bug fix?

Classify the task as BUG_FIX, investigate the root cause, and establish a regression test that reproduces the defect before implementing the fix. A fresh Verifier then reassesses the final candidate against the original approved requirement.

What is the difference between verification-first and test-driven development?

TDD controls how implementation evolves through Red-Green-Refactor cycles, while verification-first only requires that an independent oracle exists before solution edits. The oracle can be a test, type checker, schema validator, or contract check.

When can candidate review be skipped in this workflow?

Review may be omitted only for trivial, mechanical NON_BEHAVIORAL_CHANGE tasks that do not touch infrastructure, configuration, migrations, generated artifacts, or test infrastructure, and only when definitive validation has passed.

How are pure refactors verified without changing tests?

PURE_REFACTOR tasks establish a green baseline with existing behavioral verification and keep it unchanged throughout. If behavioral expectations must change, the task is stopped and reclassified.

What verification strategy works for infrastructure and configuration changes?

Infrastructure changes use natural oracles such as schema validation, policy checks, migration checks, contract validation, or lint rather than forcing shallow unit tests. Intent is classified first, then the most direct oracle is selected.