merge-issue
マージ前の事前確認(プリフライトチェック)と、完了後に自動で進む更新処理(ロールアップ)の連鎖
プリフライトチェック(マージする前に行う一連の事前確認)が全て合格しない限り、マージは実行されません。 これがこのスキルの特徴です。
- PR/MRがopen状態(既にマージ/クローズされていない)
- 最新レビューラウンドの判定がMergeable(ブロッカー0件)
- 必須承認が存在する
- CI/パイプラインがgreen(設定されていれば)
- コンフリクトなし、ベースブランチと同期済み
コマンドと主なオプション
/architect:merge-issue [item|mr|pr] [--strategy=merge|squash|rebase] [--delete-branch] [--yes-merge] [--dry-run] [--auto] [--lang=en|ja]| オプション | 意味 |
|---|---|
item|mr|pr |
対象。Issue(I1.2.3・#<iid>・URL)でも、PR/MRを直接指定してもよい。省略時はmanifestから解決する |
--strategy |
マージ方法。merge(そのまま)・squash(1コミットにまとめる)・rebase。省略時はプロジェクトの既定値 |
--delete-branch |
マージ後に作業ブランチを削除する |
--yes-merge |
確認ゲートを事前承認扱いにしてスキップする。このゲートを飛ばせる唯一の手段 |
--dry-run |
何もマージせず、何がマージされるかだけ報告する |
--auto |
途中の確認を省略する。ただしマージの確認ゲートはスキップされない |
--lang |
コメントやレポートの出力言語 |
ロールアップの連鎖
マージが成功すると、次の一連の更新(ロールアップ)が自動で起きます。
Issueをクローズ + status::done
対象のIssueが完了扱いになります。あわせて## Delivery StatusのMergedにチェックが入ります。
確認ゲートでユーザーが「未達のままマージする」と判断した受入基準は、チェックなしのまま
マージコメントに明記されます。
Sub-Epicの子タスクリストを検証
## Issuesタスクリストの該当Issueのチェックは、本来implement-backlogが実装完了時に入れています。
このスキルは入っているかを確認するだけで、漏れていた場合だけチェックを入れます
(マージされてCIがgreenなら、実装が終わっている証拠になるため)。
すべてのIssueが完了したら、Sub-Epic自体もstatus::doneになります。
Epicの子タスクリストを検証
Sub-Epicがdoneになったときだけ、## Sub-Epicsタスクリストの該当チェックを同じように検証します。
backlog-manifest.jsonを更新
このロールアップで動いたすべてのノードのimpl.statusを更新します。Issueだけでなく、
doneになったSub-Epic/Epicも対象です。親の完了をトラッカー側にしか書かないと、あとで
deliver-backlogが再開したときに、完了済みのSub-Epicを未着手と誤読してしまいます。