mcpField
S
stacked-delivery

stacked-delivery

github.com/yeachan-heoその他40.7k8 回インストール今日更新
リポジトリ

stacked-delivery について

依存関係のある変更を、相互にリンクしたPRのスタックとして出荷するワークフロースキルです。パッチIDごとに検証結果を記録し、リベース後の再検証を求め、マージ権限は人に委ねます。

主な機能

  1. 01変更ごとにブランチとリンク済みPRを作成
  2. 02スタックの各層をビルドして検証
  3. 03パッチIDごとに検証結果を記録
  4. 04リベース後に古い結果を無効化
  5. 05人が最下層から順にマージ
  6. 06チェーンの状態と検証状況を報告

活用シーン

  1. 01先行PRに依存する変更の出荷
  2. 02順次マージが必要なレビュー作業の管理
  3. 03再検証が必要なスタック層の確認

インストール

コマンドをコピーしてターミナルで実行します。

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

インストール後、Claude Code で/stacked-deliveryを入力して読み込まれたか確認します。

README（原文）English

プロジェクトの README より

この 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.

コメント

Markdown 対応