principle-sequence-verifiable-units

Sequences multi-step code changes into small units verified before advancing.

Updated Mar 27, 2026
One-click install
npx skills add https://github.com/gmackie/agent-skills --skill principle-sequence-verifiable-units-gmackie
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: principle-sequence-verifiable-units
Source: https://github.com/gmackie/agent-skills/tree/main/skills/principle-sequence-verifiable-units
Command: npx skills add https://github.com/gmackie/agent-skills --skill principle-sequence-verifiable-units-gmackie

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Large sweeps, migrations, and stacked PRs often batch many edits before any verification, so failures surface late and are hard to localize. This Skill enforces a discipline where every unit of work ends in a checkable state before the next begins. ## Core Features & Use Cases - Per-Unit Verification: Treats each edit as a before/after bracket with a known-good baseline, one change, and an immediate check. - Delivery Sequencing: Orders commits and PRs so the stack proves itself, such as a failing test first followed by the fix. - Baseline Discipline: Requires rebasing onto clean trunk so each check measures against the real baseline. - Use Case: During a codebase-wide migration, apply one file transformation, run its test, confirm green, then proceed, and stack the commits so a reviewer can replay red-to-green. ## Quick Start Apply the sequence-verifiable-units principle to break this migration into small verified steps and order the commits as a failing test followed by the fix.

Frequently Asked Questions about principle-sequence-verifiable-units

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

FAQPage Schema
How do I break a large code migration into verifiable steps?▼

Pick the smallest unit that ends in a check, such as one edit plus its test. Verify that unit before starting the next, rebasing onto clean trunk first so each check measures against the real baseline.

How should I order commits and PRs for easier review?▼

Stack commits so the sequence proves the work: a failing test first to show the bug is real, then the fix on top to show it resolved. Each commit should land on its own so the stack reads as an argument.

Why verify each change instead of testing once at the end?▼

A break caught at the unit that caused it is cheap to localize, while a break caught after a batch is buried under later edits built on a broken base. Per-unit checks keep failures attributable.

When should I not split work into small verified units?▼

The discipline targets multi-step work like sweeps and migrations; a single isolated change needs no sequencing. The overhead is minimal when an automated lever makes the per-unit check nearly free.