principle-sequence-verifiable-units
cursor/plugins
Break multi-step work into small verifiable units, sequence commits to prove the logic to reviewers.
What is principle-sequence-verifiable-units?
A principle for organizing sweeps, migrations, and similar repetitive edits into discrete, checkable steps. Apply it both during execution (verify each change before the next) and delivery (stack commits in an order that demonstrates the work's correctness to reviewers).
- Break work into small units, each ending in a verifiable state
- Check each unit before advancing to the next
- Rebase onto clean trunk so every check measures against the real baseline
- Stack commits and PRs in proof order (e.g., failing test first, then fix)
- Make per-unit verification cheap when using automated tools
How to install principle-sequence-verifiable-units
npx skills add https://github.com/cursor/plugins --skill principle-sequence-verifiable-unitsHow to use principle-sequence-verifiable-units
- 1.Identify the full scope of work (sweep, migration, or similar run)
- 2.Rebase onto clean trunk to establish a known-good baseline
- 3.Break the work into small, discrete units (each a before/after bracket)
- 4.Execute the first unit and run its verification check
- 5.Proceed to the next unit only after the current one passes
- 6.When delivering, order commits to tell a proof story (e.g., test first, then fix)
- 7.Stack PRs in sequence so each commit lands independently and reads as an argument
Use cases
- Organizing a large refactoring sweep across many files
- Sequencing a database migration with pre- and post-checks
- Stacking a series of similar edits (e.g., renaming a function everywhere)
- Delivering a feature as a series of commits that each prove correctness
- Structuring a PR so reviewers can replay the logic step-by-step
- Engineers performing large-scale refactors or migrations
- Teams using stacked PRs or commit-based code review
- Developers using AI-assisted code generation tools
- Anyone coordinating multi-step changes across a codebase
principle-sequence-verifiable-units FAQ
A unit is verifiable when you can run a check (test, lint, build, or other validation) that confirms the change is correct before moving to the next step.
Yes. Even when a lever (automated tool) does the edits, run the per-unit check anyway—it's nearly free and catches breaks early.
Stack commits in proof order: typically a failing test first, then the fix on top. Other valid orders include a baseline capture before treatment, or a scaffold before a feature.
Execution sequencing ensures you catch breaks early during development. Delivery sequencing orders commits so reviewers can replay the logic and see the work prove itself.
This complements 'prove-it-works' (which keeps checks real) and 'build-the-lever' (which makes per-unit checks cheap).
Full instructions (SKILL.md)
Source of truth, from cursor/plugins.
name: principle-sequence-verifiable-units description: "Apply to multi-step work (sweeps, migrations, runs of similar edits) and to how you stack commits and PRs. Break work into small units that each end in a verifiable state, check each before the next, and order delivery so the sequence proves itself to a reviewer." disable-model-invocation: true
Sequence work into verifiable units
Order work as a sequence of small units, each ending in a state you can check, and don't advance until the current one is green.
Why: A break caught at the unit that caused it is cheap to localize. A break caught after a batch is buried, and you have already built further on a broken base. Sequencing those same units into a delivery a reviewer can replay turns "trust me" into "watch it go red, then green."
Execution. In a sweep, migration, or any run of similar edits, verify each change before starting the next. Each unit is a before/after bracket: known-good state, one change, run the check, then proceed. Rebase onto clean trunk first so every check measures against the real baseline. When a lever does the edits, the per-unit check is nearly free. Run it anyway.
Delivery. Stack commits and PRs in the order that proves the work. The canonical shape is the failing test first, then the fix on top. Other story orders are a subtraction before the reshape, a baseline capture before the treatment, the scaffold before the feature. Each commit lands on its own and the sequence reads as an argument.
The sequencing complement to the prove-it-works principle skill, which keeps each check real, and the build-the-lever principle skill, which makes the per-unit check cheap.
Related skills
More from cursor/plugins and the wider catalog.
principle-subtract-before-you-add
Remove complexity first—delete dead code and redundancy before adding features or refactoring.
principle-type-system-discipline
Apply type-system discipline to eliminate impossible states and catch bugs at compile time.
recall
Reconstruct your recent working context from chat history and shared records to resume work efficiently.
reflect
Mine conversations for durable learnings and route them into skill edits.
review-and-ship
Review code for bugs and intent fit, run tests, and open or update a PR.
run-smoke-tests
Run Playwright smoke tests, debug failures, and verify fixes