forge-batch

IssueをWaveにまとめる

どのIssueを並行してリリースできるか、またその順序を決定します。

入力

対象範囲（$ARGUMENTS）：milestone:<name>、label:<name>、epic:<number>、またはIssue番号。任意：Waveのサイズ上限や一緒に固定するIssueなどの追加コンテキストを指定する-- <additional context>。--unattendedを指定すると承認手順を省略します。

プロセス

Step 1: 候補を収集する

issue-operationsのList Issues by Scopeで対象範囲のIssueを一覧表示し、番号、タイトル、ラベル、実行モード、依存関係の参照だけを残します。本文はIssueごとに後で読みます。その後、オープン中のPRを一度取得し、#<number>または<type>/<number>-をローカルで照合します。

gh pr list --state open --limit 100 --json number,title,headRefName,body

HITLのIssue、blockedラベルが付いたIssue、オープン中のPRがあるIssue、対象範囲外のオープン中のIssueに依存するIssueは、それぞれ理由を明記して除外します。残りはすべてAFKで、着手できます。

Step 2: 変更対象を見積もる（委任）

各候補について、その実装で変更される可能性が最も高いファイルとディレクトリである変更対象を作成します。対象範囲のIssueが5件を超える場合は、forge-scoutのサブエージェントに、安価で高速なモデルを使って並列で委任します。共有のgrepを一度で済ませられるよう、1人のscoutにつきIssueを約5件割り当てます。それ以外の場合はインラインで見積もります。implementの事前調査とは異なり、ここではscoutにIssueを渡します。変更対象はそれらのIssueに関するものです。

各Issueについて、明示的に記載されているパスをすべて列挙し、Issueで言及されている概念（ルート、テーブル、コンポーネント、メッセージキー）をgrepして、それらを定義しているファイルを追加します。パスのみを返してください。

サブエージェントに渡す入力： Role: forge-scout、Issue本文、コードベースへのアクセス権。 期待される出力： Issueごとに#<number>: <paths...>。

Step 3: Waveを作成する

2つのIssueの変更対象に同じファイルが含まれる場合、またはunattended-configにある同じシリアライズ対象リソースのglobに両方が一致する場合、これらのIssueは競合します。Issue Aの本文に依存関係（depends on #B、blocked by #B、after #B）が記載されている場合、Issue AはIssue Bに依存します。

優先度ラベル、次に番号の順にIssueを処理し、すでに配置されたIssueと競合せず、すべての依存先が前のWaveにある最も早いWaveに配置します。追加コンテキストで別途指定がない限り、1つのWaveは最大10件とします。ファイルは共有しないもののディレクトリを共有するIssueは同じWaveに配置できますが、担当者が却下できるよう隣接としてマークします。

Step 4: 確認する

AskUserQuestionでバッチを提示し、承認するか、Issueを移動するか、除外するかを確認します。**unattendedモードの場合：**確認を省略して出力します。

Step 5: バッチを出力する

以下の出力形式を使用します。起動行には、変数が設定されていれば$FORGE_LAUNCHERを記載し、そうでなければユーザーが手動で開始する対象の番号のみを記載します。

出力形式

## Batch: <scope>

### Wave 1 — <n> Issues
| # | Title | Touch set | Notes |
|---|-------|-----------|-------|
| 123 | feat(api): ... | src/api/x.ts, src/api/x.test.ts | |
| 124 | fix(ui): ... | src/ui/y.tsx | adjacent to #125 |

launch: <launcher> 123 124 ...

### Wave 2 — <n> Issues (after Wave 1 merges)
...

### Excluded
- #130 — HITL
- #131 — open PR #400 already

ガイドライン

• 変更対象は見積もりです — その旨を明記します。Waveは担当者が承認する見込みであり、保証ではありません
• シリアライズ対象リソースは常に優先されます — 1つのWaveにマイグレーションが2つあると、必然的にマージ競合になります
• 後続のWaveは暫定です — Waveがマージされた後に再実行します。コードが取り込まれると変更対象も変わります

関連スキル

前： forge-create-issueがIssueをAFKまたはHITLに分類します。Waveに含めるのはAFKのIssueのみです。 後： Wave内の各Issueは、$FORGE_LAUNCHERを使うか手動で、forge-ship --guardを指定して開始します。

使用例

/forge-batch milestone:v1.1.0
/forge-batch label:ready
/forge-batch epic:601
/forge-batch 610 611 612 613 -- cap waves at 4
/forge-batch --unattended label:ready