principle-sequence-verifiable-units

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

6.6k|542|Updated Jan 23, 2026
One-click install
npx skills add https://github.com/cursor/plugins --skill principle-sequence-verifiable-units
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: principle-sequence-verifiable-units
Source: https://github.com/cursor/plugins/tree/main/pstack/skills/principle-sequence-verifiable-units
Command: npx skills add https://github.com/cursor/plugins --skill principle-sequence-verifiable-units

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Large sweeps, migrations, and stacked PRs often batch many edits and verify only at the end, burying failures and forcing reviewers to trust unproven changes. 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, never deferring verification to a final batch.
  • Delivery Ordering: Structures commits and PRs so the sequence proves itself, such as a failing test first (red) followed by the fix (green), letting reviewers replay the argument.
  • Use Case: During a codebase-wide migration, apply one edit, run its test, confirm green, then proceed, and stack the resulting commits so a reviewer sees each change land independently.

Quick Start

Ask the agent to break this 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 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 in a stacked PR for review?

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

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 edits built on a broken base. Per-unit checks keep failures attributable.

When is batch verification acceptable instead of per-unit checks?

This principle argues batch verification is not acceptable for sweeps or migrations, even when an automated lever makes edits. The per-unit check is nearly free with automation, so it should still run every time.

Does this apply only to tests or also to other checks?

It applies to any check that confirms a unit ends in a known-good state, including builds, lints, or baseline captures. The key requirement is that each unit is verified before advancing to the next.