principle-sequence-verifiable-units

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

Updated Sep 2, 2026
One-click install
npx skills add https://github.com/jnyross/pstack-muse --skill principle-sequence-verifiable-units-jnyross
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: principle-sequence-verifiable-units
Source: https://github.com/jnyross/pstack-muse/tree/main/skills/principle-sequence-verifiable-units
Command: npx skills add https://github.com/jnyross/pstack-muse --skill principle-sequence-verifiable-units-jnyross

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: Run a check after each edit in a sweep or migration instead of one final batch validation. - Red-to-Green Delivery Ordering: Stack commits and PRs so a failing test lands first and the fix follows, letting reviewers replay the proof. - Baseline Discipline: Rebase onto clean trunk first so every check measures against the real baseline. - Use Case: During a codebase-wide migration, apply one edit, run its test, confirm green, then proceed—producing a commit stack a reviewer can follow as an argument. ## Quick Start Ask the AI to break this migration into small verifiable units and order the commits so each one proves itself.

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

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

The skill argues it rarely is: even when an automated lever performs the edits, the per-unit check is nearly free and should still run. Deferring verification to a final batch is explicitly discouraged.

Does this apply only to code migrations?

No, it applies at two altitudes: execution of any run of similar edits such as sweeps and migrations, and delivery of stacked commits and PRs ordered so a reviewer can replay the proof.