菜单
ready ラベル付き Issue を古い順に1件ずつ直列で消化する半自動ループ。各Issueを /impl の手順で実装し、品質ゲート（pr-review が Low 以下 + E2E green + CI green）を満たせば /merge 相当で自動マージする。条件を満たさないものは needs-merge / blocked で人に戻す。実装ロジック本体は /impl が持つ。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
@issue_note.txt の課題No、または Evernote 共有リンク（ノート下書き）をもとに、GitHub Issueを作成する。対応種別に応じてfeature/bugfixテンプレートを使い分ける。
PRをMerge commit方式でマージし、リモート・ローカル両方のfeatureブランチを削除して司令塔ベースブランチを最新化する。マージのタイミングはユーザーが決める。
Issue起点の実装計画を作成する。Issueの内容とプロジェクトの設計ドキュメントを照合し、影響範囲・実装方針・テスト方針を含む計画を出力する。
Playwright MCPを使って、既に起動済みのlocalhost環境に対してE2E観点の動作確認を行うための運用ルール。
PRのコードレビューを実施し、レビュー結果をPRコメントとして投稿する。アーキテクチャ観点でのコードレビュー。
ブランチ・Git運用ルール。feature ブランチ作成、コミット、プッシュ、PR作成の手順。品質チェック後のGit操作フロー。
| name | loop-issues |
| description | ready ラベル付き Issue を古い順に1件ずつ直列で消化する半自動ループ。各Issueを /impl の手順で実装し、品質ゲート（pr-review が Low 以下 + E2E green + CI green）を満たせば /merge 相当で自動マージする。条件を満たさないものは needs-merge / blocked で人に戻す。実装ロジック本体は /impl が持つ。 |
| when_to_use | ready ラベルで仕様承認済みの Issue をまとめて自動消化したいとき、「ループで消化して」「loop-issues」「溜まったIssueを片付けて」などの発言時。1件だけ・じっくり見ながら進めたいなら従来どおり /plan → /impl を直接使う。 |
| agent | frontend-engineer |
引数: $ARGUMENTS（任意。処理する最大件数。省略時は既定 3。例: /loop-issues 5）
実装フローの本体は /impl が持つ（worktree作成・前提チェック・実装・テスト・PR・後片付け）。
このスキルは「ready ラベル付き Issue を1件ずつ拾い、/impl 相当の手順を直列で回し、
品質ゲートを満たしたものだけ /merge 相当で自動マージする」司令塔オーケストレーターである。
設計の全体像・共有インフラ制約は docs/worktree-workflow.md を参照。
各 Issue は「実装 → PR作成 → pr-review → E2E → CI見届け → 条件を満たせば自動マージ」まで 1件で完結させる（1件マージし切ってから次の1件へ。共有DBは1つなので直列は維持される）。
自動マージしてよい条件（すべて満たすこと。1つでも欠けたら人に戻す）:
ready 付き（= 計画承認の代理）で、仕様ガード（1-2）を通過している（blocked でない）needs-merge で人に戻す（1-4b 参照）。gh pr checks <PR> --watch で見届けて全 green（1-7 参照）→ 1〜4 を満たす = /merge <PR> 相当を loop が自動実行（Merge commit + Issueクローズ + リモート/ローカル
ブランチ削除 + 司令塔 develop 最新化）。満たさないものは needs-merge（マージ可能だが人の判断が要る）または
blocked（失敗・要対応）で残し、人が後から /merge / /review-fix する。
なぜマージを全自動にしないか: CI green は「コンフリクト無し・テスト通過」を保証するだけで、設計判断の 妥当性は保証しない。pr-review で Medium 以上が出た＝判断が割れた変更は、機械的に直せても develop へ 無人で入れず人に最終判断を残す。「機械的に安全なものだけ自動で流し、判断が割れたものは人が見る」という リスク比例の自動化。最終マージ権を完全には手放さない設計。
このリポジトリには2つの作業モードがあり、ready ラベルが両者の分界線である。
ready ラベル付き Issue だけを対象にする。
ready を付けた = 「仕様が明確で実装してよいと人が判断済み」= 計画承認の代理。
そのため、ループ内では /plan の個別承認も /impl の3択も出さず、品質ゲートを満たせば自動マージまで進める。
品質ゲートを満たさないものだけ人に戻す（上記「条件付き自動マージ」参照）。ready を付けていない Issue。従来どおり人が /plan で計画を見て承認し、
/impl を回し、2-2-2 の3択で判断する。このスキルは手動モードに一切干渉しない。進行ラベル（in-progress / needs-merge / blocked）はこのループ専用。
手動モードの Issue にこれらを付けてはならない。手動とループでラベルがちぐはぐにならないようにするための最小ルール。
git branch --show-current が develop（司令塔）であること。develop 以外なら
「git switch develop してから再実行してください」と案内して停止。git status --porcelain が空）。dirty なら停止して扱いを確認。develop を最新化する: git pull --ff-only origin develop
（失敗時は勝手に rebase/merge せず報告して停止。/impl 1-0 と同じ作法）。ready / in-progress / needs-merge / blocked）が GitHub 上に存在すること。
存在しなければ作成を促す（このスキルでは勝手に作らない。リモートへの変更のため）。supabase start → pnpm e2e:setup を行う（破壊的でないが、起動した旨は報告する）。
Docker が起動できない等で E2E 環境が用意できない場合は、自動マージ条件③を満たせないため、該当 Issue は
needs-merge で人に戻る（マージはされない）。その旨を完了報告に明記する。gh issue list --state open --label ready --json number,title,labels --limit 100
ready が付き、かつ in-progress が付いていない open Issue を**古い順（番号昇順）**に並べる。$ARGUMENTS（既定3）件だけを今回の処理対象とする。
上限で打ち切った残り件数があれば、完了報告に明記する（黙って切り捨てない）。共有インフラ制約: 全 worktree は単一 Supabase(54421)・単一物理DB・固定ポートを共有する。 このループは必ず1件ずつ直列で処理し、同時に存在する worktree は常に1つに保つ。
in-progressラベルが「いま処理中」のロック代わりになる。複数 Issue を並列実装してはならない。
各対象 Issue について、以下を順に行う。1件完了してから次の1件へ進む。
gh issue edit <N> --remove-label ready --add-label in-progress
/plan の調査手順（gh issue view <N> → 設計ドキュメント照合 → 関連ファイル確認 → 横展開スキャン）を
内部的に実行する。ただし ready が承認の代理であるため、ユーザーへの計画提示・承認待ちは行わない。ready でも実際には仕様に穴がある Issue」を検知して推測実装を防ぐこと。
以下に該当したら実装に進まず blocked 化する:
blocked 化の手順（→ 1-X の失敗時共通処理へ）。/impl <N> の Phase 1〜2-2-1 の手順を自分の文脈でなぞって実行する
（worktree作成 → 実装 → UT → format/lint → 設計doc同期 → コミット → push → gh pr create --base develop（本文に Closes #N）→ worktree撤去）。
/impl を呼び出さない。context:fork / agent: が無視される既知制約のため、
impl の手順を本スキル（agent: frontend-engineer）の文脈で辿る。pr-review（system-architect 委譲のコードレビュー）は実行する（→ 1-4）。
レビューはループでも必須。ここを止めない。blocked（1-X）。「2-2-2 を丸ごとスキップ」ではない。/understand 自動発動を行わない（ループ実行中の宿題化は無効）。subagent_type: "frontend-engineer" を指定する。pr-review の手順で PR にレビューコメントを投稿する（/impl 2-2-2 と同じ品質ゲート。
コードは読むだけ・共有DBに触らないため、ループでも安全に走る）。pr-review を Skill ツールで呼ばない。Skill 経由だと pr-review の
frontmatter（agent: system-architect / context: fork）が無視されるため、代わりに
subagent_type: "system-architect" のサブエージェントを直接起動し、pr-review スキル本文
（.claude/skills/pr-review/SKILL.md）のレビュー観点・コメントフォーマットに従ってレビューさせ、
gh pr comment <PR番号> で PR にレビュー結果を投稿させる。
pr-review スキルが単一の真実の源（このファイルに複製しない）。/impl 2-2-2 のエージェント例外と同じ理由）。needs-merge 止まり。1-5 参照）。レビューで Medium 以上の指摘が出た場合、自動で修正を取り込む。暴走防止のため再レビューは最大1回。
方針（ユーザー合意・2026-06-29 / 更新 2026-06-30）: Medium 以上で自動 review-fix。再レビュー1回、 それでも Medium 以上が残れば
blocked化して人にエスカレーションする。 Medium 以上が一度でも出た Issue は、再レビューで解消しても自動マージしない（needs-mergeで人に戻す）。 判断が割れた変更は、機械的に直せても develop へ無人で入れず、人に最終マージ判断を残すため （条件付き自動マージの方針。冒頭「条件付き自動マージ」参照）。
手順:
修正の取り込み（review-fix 相当）: review-fix を Skill ツールで呼ばず、
subagent_type: "frontend-engineer" のサブエージェントを直接起動し、review-fix スキル本文
（.claude/skills/review-fix/SKILL.md）の手順に従って Medium 以上の指摘のみをコード修正させる。
git worktree add <パス> origin/<headRef> -b ... ではなく、既存ブランチをチェックアウトする形。
具体的には git worktree add <パス> <headRefName>）。修正後 UT / format / lint を通し、コミットして
同じ feature ブランチへ push する。完了したら worktree を撤去する。blocked 扱いとしてエスカレーションする。再レビュー（最大1回）: 1-4 と同じ方式で system-architect を再起動し、修正後の PR を再レビューさせて PR にコメント投稿する。
needs-merge で人に戻す（解消しても自動マージ対象に復帰しない）。blocked 化）。2回目の自動 review-fix は行わない。エスカレーション（blocked）: 再レビュー後も Medium 以上が残る、または 1 で人の判断が要ると判断した場合:
gh issue edit <N> --remove-label in-progress --add-label blocked
gh issue comment <N> --body "loop-issues: 自動 review-fix 後も Medium 以上の指摘が残ったため blocked。PR #<PR番号> のレビューコメントを確認し手動対応してください。"
/review-fix <PR番号> で続きを対応できる）。blocked も Phase 1-S の「連続2件失敗」カウントに含める。pr-review（1-4）と自動 review-fix（1-4b）が終わった時点で、**自動マージ条件②（pr-review 最大 Low 以下）**を評価する。
「Medium 以上が一度でも出た」マークが付いている（1-4 / 1-4b でマーク済み）→ 自動マージ対象から外す。
needs-merge に張り替え、人に戻す:
gh issue edit <N> --remove-label in-progress --add-label needs-merge
gh issue comment <N> --body "loop-issues: pr-review で Medium 以上が出たため（自動 review-fix の有無に関わらず）自動マージは行いません。PR #<PR番号> を確認し、問題なければ /merge <PR番号> でマージしてください。"
その後、この Issue の処理は終了（E2E / CI見届け / 自動マージはスキップ）。次の Issue へ。
Low 以下 / 指摘なし（Medium 以上マーク無し）→ 2-E（マージ前 E2E）へ進む。条件③④を続けて評価する。
worktree は 1-3 で撤去済みのため、この Issue の feature ブランチをチェックアウトした検証用 worktree を再作成し、 共有DBに実接続して E2E を実行する。共有DB競合を避けるため必ず1件ずつ直列（同時に検証 worktree は1つ）。
docs/e2e.md に従い supabase start →
pnpm e2e:setup（seed投入 + テストユーザー作成）。環境起動は破壊的でないが、未起動から立ち上げる場合は
完了報告に明記する。git worktree add <パス> <headRefName>（既存 feature ブランチをチェックアウト）。
worktree 内で pnpm install し、メインの apps/*/.env.local と apps/*/.env.e2e.local をコピーする
（env はブランチに含まれないため。/impl のworktree初期化と同じ手続き）。subagent_type: "qa-engineer" で（または司令塔が直接）実行する。
新規追加した spec は develop に無いため、この検証 worktree 上で実行するのが正しい（spec は PR ブランチにある）。
green → 1-7（CI見届け＋自動マージ）へ進む。
赤（落ちた） → needs-merge に張り替えて人に戻す（マージ前に品質が担保できないため自動マージしない）:
gh issue edit <N> --remove-label in-progress --add-label needs-merge
gh issue comment <N> --body "loop-issues: マージ前 E2E が失敗したため自動マージを見送り。PR #<PR番号> の E2E を確認し手動対応してください。"
この Issue の処理は終了（次へ）。E2E 赤も Phase 1-S の連続失敗カウントに含める。
git worktree remove ...）。撤去できない場合は報告に明記。ここに到達した Issue は、条件①（ready/仕様ガード通過）②（pr-review Low 以下）③（E2E green）を満たしている。
最後に条件④（CI 全 green）を見届け、満たせば /merge 相当を自動実行する。
CI 完了の見届け（/merge 1-1 と同じ作法）:
gh pr checks <PR番号> --watch --interval 30
終了コード 0（全チェック pass）→ 2 のマージへ。
非0（fail / cancelled 等）→ マージせず needs-merge に張り替えて人に戻す:
gh issue edit <N> --remove-label in-progress --add-label needs-merge
gh issue comment <N> --body "loop-issues: CI が green でないため自動マージを見送り。失敗チェック: <チェック名>。PR #<PR番号> を確認してください。"
この Issue の処理は終了（次へ）。CI 赤も Phase 1-S の連続失敗カウントに含める。
マージ実行（/merge スキル相当を loop が実行）: /merge スキル本文（.claude/skills/merge/SKILL.md）の
手順 2〜5 をこの文脈でなぞって実行する（Skill ツールで /merge を呼ばない。手順を辿る）:
gh pr merge <PR番号> --merge --delete-branch（Merge commit 方式 + リモートブランチ削除）/merge 2-1 参照）:
PR本文の Closes #N / ブランチ名から Issue 番号を抽出し gh issue close <N> --comment "PR #<PR番号> のマージに伴いクローズ"。
in-progress ラベルは外さなくてよい（Issue が closed になれば open 一覧に出ないため
次ループに影響しない）。ただし整合のため、クローズ前に gh issue edit <N> --remove-label in-progress で
進行ラベルを落としてからクローズすると、ラベル状態がきれいに残る（任意だが推奨）。git pull --ff-only origin develop（マージコミットを取り込む。失敗時は
勝手に rebase/merge せず報告して停止）。git branch -d <headRefName>（存在しなければスキップ。-D へ勝手に
切り替えない。/merge 4 と同じ）。git fetch --prune origin。マージ成功を記録（完了報告の「自動マージした Issue 一覧」に PR番号・URL・マージコミットを載せる）。次の Issue へ。
blocked 化してスキップ。各ステップから参照される横道）実装失敗・コンフリクト・仕様の穴（1-2）のいずれかに該当したら、そのIssueは直さずに:
gh issue edit <N> --remove-label in-progress --add-label blocked
gh issue comment <N> --body "loop-issues: <失敗理由（実装失敗/仕様の穴/コンフリクト等）の要約>。手動対応が必要です。"
git worktree remove ...）。撤去できない場合は報告に明記。blocked も Phase 1-S の「連続2件失敗」カウントに含める。blocked 化（実装失敗 / 仕様の穴 / コンフリクト / review-fix 後も Medium 以上残存）needs-merge に戻したもの（品質が担保できずマージできなかった）needs-merge に戻したもの（1-5）。
これは実装・テストは通っており、設計判断を人に委ねただけで「失敗」ではない。連続失敗の暴走検知対象外。
（ただし完了報告には理由付きで載せる）$ARGUMENTS、既定3）に達したら正常終了する。旧 Phase 2（IT/E2E のまとめ消化）は廃止。E2E は各 Issue の処理内（2-E）でマージ判定の直前に直列実行する 設計に変わった（自動マージ条件「マージ前に E2E green」を満たすため）。1件ずつ「実装→pr-review→E2E→CI→ 自動マージ」を完結させるので、まとめフェーズは不要になった。共有DBは1つ・検証 worktree も常に1つで直列性は維持。
以下を報告する:
ready 対象の総件数（上限で残した件数があれば明記）needs-merge で人に戻した Issue 一覧（Issue番号・PR番号・PR URL・戻した理由：
pr-review で Medium 以上 / E2E 赤 / CI 赤 のどれか）blocked にした Issue 一覧（Issue番号・理由）needs-merge の Issue は PR を確認し、問題なければ /merge <PR番号> でマージして
ください。blocked の Issue は PR のレビューコメント / E2E 失敗を確認し、/review-fix <PR番号> 等で
手動対応してください。自動マージ済みの Issue は develop に統合・クローズ済みです」ready ラベルが付いていない Issue（= 手動モード対象）に触れること。needs-merge / blocked で人に戻す。needs-merge 止まり。
判断が割れた変更は人に最終マージ判断を残す。1-4b / 1-5 参照）。--watch 全 green を確認）。blocked 化してスキップする）。/impl / /plan / pr-review / review-fix / merge を呼び出すこと（context:fork/agent: が
無視されるため、手順を文脈で辿る。pr-review/再レビューは subagent_type: "system-architect"、
review-fix / E2E は subagent_type: "frontend-engineer" / "qa-engineer" を直接起動する。1-4 / 1-4b / 2-E 参照）。blocked。1-4b 参照）。-d が失敗した際に -D へ勝手に切り替えること（/merge 4 と同じ。報告して委ねる）。