mcpField
S
stacked-delivery

stacked-delivery

github.com/yeachan-heoOther40.7k8 installsUpdated today
Repository

About stacked-delivery

A workflow skill for delivering dependent changes as a stack of linked pull requests. It tracks verification by patch ID, requires re-verification after rebases, and leaves merging authority with a human.

Key features

  1. 01Create branches and linked PRs per change
  2. 02Build and verify each stack layer
  3. 03Track verdicts against patch IDs
  4. 04Invalidate stale verdicts after rebases
  5. 05Land layers bottom-up with human merges
  6. 06Report chain status and verification

Use cases

  1. 01Ship changes that depend on earlier PRs
  2. 02Manage review-gated work that merges sequentially
  3. 03Check which stack layers need re-verification

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/yeachan-heo/oh-my-claudecode --skill stacked-delivery

After installing, type/stacked-deliveryin Claude Code to confirm it loaded.

Details

From the project README

Stacked Delivery

Some queues cannot merge independently — each change depends on the last — so they ship as one stacked chain: PR 2 branches on PR 1, PR 3 on PR 2. The chain makes review sequential and landing strictly bottom-up; this skill keeps that honest.

When to use

  • changes depend on each other and the user chose stacking over independent PRs
  • review gating means only the bottom PR can actually merge at a time

When not to use

  • changes are independent — parallel PRs merge faster and fail smaller
  • the user wants everything in one PR — that is execute with a bigger brief

Workflow

  1. Cut the stack: one branch and PR per change, each branched on the last; the brief for each PR comes from sharpen/architect as usual. Every PR description links its parent and child.
  2. Build and verify each layer with its own checks — a red middle PR blocks the whole chain, so fix forward before adding layers on top.
  3. Record patch-ids: verification verdicts (from verify) record the head SHA they were earned on, in .omc/state/verification-ledger.tsv — the ledger's sha field. A verdict applies only to that exact patch. Review verdicts (interrogate pass/revise/block) are tracked in the PR's review thread, not the verification ledger — the ledger's vocabulary is verification evidence, and review outcomes have their own lane.
  4. On rebase: any PR whose base moved has its verdicts invalidated for the affected layers — re-run the checks and record fresh verdicts before the chain is "green" again. A stale green is the stack's most dangerous lie.
  5. Land bottom-up only: the human merges PR 1; the stack rebases onto the new trunk; re-verify; PR 2 becomes the new bottom. This skill never merges — landing authority stays with the human (babysit rules apply).
  6. Report: the chain shape (PR list with parent links), each layer's verdict and patch-id, and which layers are re-verified against the current trunk.

Rules

  • Never merge, rebase, or force-push shared branches on your own; rebase of own-branch layers uses --force-with-lease and says so.
  • Never present a layer as green whose base moved after its verdict was earned — the ledger's patch-id is the truth.
  • A failing layer stops the chain at that layer; layers above are blocked-and-waiting, not green.

Comments

Markdown supported