mstack-backlog-triage

mstack バックログのトリアージ

トラッカーの未解決イシューを読み、それぞれの内容と対応時期を判断して、次の担当先に引き渡します。出力はトリアージ表と、ユーザーが文面を一語一句承認した場合のトラッカーへのコメントおよびラベル変更です。仕様書、コード、計画は作成しません。仕様が必要なイシューは mstack-write-specs に、診断が必要なバグは mstack-diagnose に、それ以外のイシューはこのホストの mstack レビューワークフローに回します。

ホストツール

役割	Claude Code	Codex
質問ツール	AskUserQuestion	チャットで番号付きの質問をして、返信を待つ
サブエージェントツール	Agent	セッションにエージェントツールがあればそれを使い、なければ自分で手順を実行する
スキルフォルダー	このスキルの読み込み時に表示されたベースディレクトリ	この SKILL.md があるフォルダー
gh コマンド	直接実行する	サンドボックスでネットワークが無効になるため、承認済み（権限昇格済み）コマンドとして実行する
<scratch>	リポジトリ外にあるセッションのスクラッチフォルダー	${TMPDIR:-/tmp}/mstack-triage-<repository name>

このスキルのファイル

ファイル	使用箇所
references/triage-rules.md	手順 3～6：根拠、重複の検索、分類、推奨事項、振り分け先、表
references/drafting.md	手順 7 と 8：コメント、ラベル、承認、投稿
scripts/list-open-issues.sh	GitHub での手順 2

基本ルール

1. すべて読む。 対象範囲の未解決イシューをすべて、本文全体とすべてのコメントを含めて読みます。一覧のタイトルは根拠になりません。また、コメントですでに回答済みのイシューに新たな推奨事項を付けてはいけません。
2. すべての判断に根拠を示す。 各分類と推奨事項について、判断の根拠となったもの（再現、検索、コメント、コードパス）を示します。確認できなかった事実は、推測ではなく質問として扱います。
3. 重複検索なしに「今」へ回さない。 重複検索を実行し、重複が見つからなかったイシューだけを現在のバッチに含めます。
4. 下書きを作成し、提示してから投稿する。 ユーザーが正確な文面とラベル変更を承認するまでは、トラッカーに何も書き込みません。承認は、下書きを提示したメッセージより後のメッセージで行われる必要があります。
5. 担当範囲を守る。 仕様書、コード、計画、リリースには手を出さず、作業の振り分けだけを行います。

1. 開始

1 回のメッセージで目的を言い換え、質問ツールを使って質問します。依頼ですでに回答済みの質問は省略します。

1. どのイシューですか？ トラッカーと絞り込み条件を確認します。すべての未解決イシュー（推奨）、またはユーザーが指定したラベル、マイルストーン、検索条件のいずれかです。
2. 次のバッチの規模はどれくらいですか？ 現在のバッチに含められるイシューの数です。チームの最近のペース（直近数週間にクローズされたイシュー数）が確認できる場合は、それをもとに数を提案します。確認できない場合は 5 件を提案します。
3. トラッカー更新の下書きを作成しますか？ コメントとラベル変更の下書きを作成して承認を得る（推奨）か、表のみを作成するかを確認します。

2. 収集

1. まずリポジトリ独自のルール（CONTRIBUTING、AGENTS.md、CLAUDE.md、.github/ISSUE_TEMPLATE/ 以下のイシューテンプレート）を読みます。適切な報告の定義や、各ラベルの意味が記載されている場合があるためです。

2. GitHub では、対象範囲の未解決イシューをすべて一覧表示し、一覧が完全であることを確認します。

   bash <skill-folder>/scripts/list-open-issues.sh <owner/repo> <scratch>/open-issues.json
   

   このコマンドは本文とコメントを保存し、保存された件数がリポジトリの未解決イシュー数と異なる場合は失敗します。これは、gh issue list がデフォルトでは 30 件までしか表示せず、そのことを通知しないためです。対象範囲を絞る場合は、一覧を取り直すのではなく、保存した一覧を絞り込みます。その後、各イシューを gh issue view <n> --repo <owner/repo> --json number,title,body,labels,comments,author,createdAt,updatedAt,url で全文確認します。

3. 別のトラッカーを使う場合は、セッションに CLI または接続済みツールがあればそれを使います。なければ、ユーザーにイシューをエクスポートまたは貼り付けてもらい、提供された内容のみを対象にトリアージすることを伝えます。

4. バックログが大きい場合は、このスキルの参照資料とともにイシューを新しいサブエージェントへグループ単位で割り当て、各サブエージェントに根拠付きの表の行を作成してもらいます。表の行を統合し、イシュー間の重複比較は自分で行い、最終表を仕上げます。

3. エビデンス

各イシューについて、references/triage-rules.md › イシューごとのエビデンスに従い、情報がそろっているか、バグの場合は簡単に再現できるか（手間がかからない場合）、すでに実装されているか、以前に却下されたことがあるかを収集します。

4. 重複

クローズ済みのイシューも含め、すべてのイシューについてreferences/triage-rules.md › 重複検索に従って重複を検索します。オープン中のイシュー同士も比較します。実施した検索を表の最後の列に記録します。

5. 分類して提案

references/triage-rules.mdに従って、各イシューにクラスを1つ、推奨対応（now、next、defer）のいずれかを1つ、対応先、およびエビデンスに基づく理由を1行で記入します。ステップ1のバッチサイズに達するまで、価値、コスト、影響度の順に評価してnowに分類します。仕様または事前の診断が必要なイシューは、その対応先とともにnextに分類します。

6. 表を提示

references/triage-rules.md › トリアージ表の定義にあるとおりのトリアージ表を提示し、その後に合計と、十分にトリアージできなかったイシューを記載します。ユーザーから求められた場合は、後でデリバリーワークフローが読み込めるよう、指定されたファイルに保存します。トラッカーの更新案を作成する前に、各行に修正がないかユーザーに確認します。

7. トラッカーの更新案を作成

ユーザーが更新案を希望した場合（ステップ1、質問3）、references/drafting.mdに従ってコメントとラベル変更の案を作成し、各案を確認して、承認用に1つの番号付きリストですべて提示します。その後、待機します。

8. 承認された内容を投稿

ユーザーが承認した項目のみを、承認されたとおりに、references/drafting.md › 投稿にあるコマンドで投稿します。各イシューを再確認し、変更された内容と失敗した内容を報告します。

9. 引き継ぎ

次の順序で報告します。

1. 目標と結果を1行で示します。トリアージしたイシュー数と、now、next、deferred、またはクローズ提案に分類した件数を記載します。
2. トリアージ表、またはその保存先のパス。
3. 投稿した内容と、作成したものの承認されなかった案。
4. 各対応先の次のステップを、ユーザーの選択肢として示します。
   • nowの行：このホストのmstackレビュー用ワークフロー（Claude Codeではmstack-codex-review-workflow、Codexではmstack-claude-review-workflow）に表を作業項目として渡します。
   • mstack-write-specsに割り当てた行：イシューから開始し、イシューごとに仕様を1つ作成します。
   • mstack-diagnoseに割り当てた行：行に記載された不足情報から開始し、バグごとに診断を1つ行います。

その後、終了します。ユーザーから依頼されない限り、これらを開始しないでください。