principle-sequence-verifiable-units

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

1|Updated Aug 27, 2025
One-click install
npx skills add https://github.com/IgorGanapolsky/Random-Timer --skill principle-sequence-verifiable-units-igorganapolsky
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: principle-sequence-verifiable-units
Source: https://github.com/IgorGanapolsky/Random-Timer/tree/main/.cursor/skills/principle-sequence-verifiable-units
Command: npx skills add https://github.com/IgorGanapolsky/Random-Timer --skill principle-sequence-verifiable-units-igorganapolsky

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Large sweeps, migrations, and batches of similar edits often bury failures deep in a pile of changes, making bugs expensive to localize and forcing reviewers to trust unverified work. This Skill structures that work so every unit ends in a checkable state and the commit sequence itself proves correctness. ## Core Features & Use Cases - Per-Unit Verification: Breaks sweeps and migrations into before/after brackets where each edit is checked before the next begins, never deferring validation to a final batch. - Ordered Delivery: Stacks commits and PRs so the sequence reads as an argument, such as a failing test first followed by the fix, or a baseline capture before the treatment. - Use Case: During a codebase-wide migration, apply one edit, run its test to confirm green, then proceed, and stack the commits so a reviewer can replay the red-to-green progression. ## Quick Start Apply this principle to break my migration into small verifiable units and order the commits so each one is checked before the next.

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 goes from red to green before starting the next, and never defer all validation to a final batch run.

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

Stack commits so the sequence proves the work: a failing test first, then the fix on top. Other valid orders include a subtraction before a reshape or a baseline capture before the treatment, with each commit landing on its own.

Why verify each change instead of testing at the end of a sweep?

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

When should I rebase during a multi-step refactor?

Rebase onto clean trunk before starting the sequence so every per-unit check measures against the real baseline. This prevents checks from passing against stale code that no longer reflects the target branch.

Does per-unit verification still matter when a script automates the edits?

Yes. When an automated lever performs the edits, the per-unit check is nearly free, so run it anyway. Automation reduces the cost of verification but does not remove the risk of a broken intermediate state.