principle-sequence-verifiable-units

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

4|1|Updated Dec 16, 2023
One-click install
npx skills add https://github.com/Shtian/AuthentiClash --skill principle-sequence-verifiable-units-shtian
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: principle-sequence-verifiable-units
Source: https://github.com/Shtian/AuthentiClash/tree/main/.claude/skills/principle-sequence-verifiable-units
Command: npx skills add https://github.com/Shtian/AuthentiClash --skill principle-sequence-verifiable-units-shtian

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Large sweeps, migrations, and batches of similar edits often bury breakages, making failures expensive to localize and hard for reviewers to trust. This Skill structures work so each change is checked before the next begins. ## Core Features & Use Cases - Per-Unit Verification: Treats every edit as a before/after bracket with a known-good state, one change, and a check before proceeding. - Stacked Delivery Ordering: Orders commits and PRs so the sequence proves itself, such as a failing test first followed by the fix. - Use Case: During a codebase-wide migration, apply one edit, run its test, confirm green, then move on, and stack the commits so a reviewer can replay the story red to green. ## Quick Start Apply this principle to break my migration into small verifiable units and order the commits so each one lands green on its own.

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 migration into verifiable steps?▼

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

How should I order commits and PRs for review?▼

Stack commits in the order that proves the work: the canonical shape is a failing test first, then the fix on top. Other orders include a subtraction before a reshape or a scaffold before the feature.

Why verify each change instead of testing 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 work built on a broken base. Per-unit checks keep failures attributable.

When should I run checks if a tool automates the edits?▼

Run the per-unit check anyway even when a lever does the edits and the check is nearly free. The point is that each unit ends in a verified state regardless of how the change was produced.

What are the limitations of sequencing work into small units?▼

It requires a check that can run per unit, so work without fast, reliable tests benefits less. It also adds discipline overhead on trivial single changes where batching carries no localization risk.