手順
- •
引数の確認
- •
$ARGUMENTSからIssue番号を取得する（スペース区切り、#プレフィックスは除去） - •引数未指定時は「Issue番号を指定してください」と報告して終了
- •
- •
各Issueについて情報取得（可能な限り並列実行）
- •
githubスキル（issue-get.sh）でIssueの内容（タイトル、本文、ラベル、状態）を取得 - •
githubスキル（issue-sub-issues.sh）でサブIssueの有無を確認
- •
- •
対応要否の判定 各Issueについて、まずIssueが既にクローズされているか確認します。クローズ済みの場合、その旨を報告してこのIssueの処理を終了します。 オープンなIssueについては、以下の基準で対応の必要性を判定します。
判定基準:
対応必要（後続のstory/task判定へ進む）:
- •具体的な変更内容や改善要望がIssue本文に記載されている
- •バグ報告が含まれている
- •実装すべき機能が記述されている
対応不要（クローズ対象）:
- •Issue本文に「既に実装済み」「問題が解決済み」などクローズ条件を満たす記載がある
- •重複Issueであることが本文やコメントで明示されている
- •対象となる機能やファイルがコードベースに存在しないことが明らか
- •Issue本文が空または意図不明で判断材料が不足している
対応不要と判定した場合の処理:
- •
githubスキル（issue-add-comment.sh）で対応不要の理由を日本語でコメント追加- •コメント例: 「このIssueは既に対応済みのため、クローズします。」
- •理由を具体的に記載すること
- •
githubスキル（issue-update.sh）の--state closed --state-reason completedまたは--state closed --state-reason not_plannedでIssueをクローズ- •実装済み・解決済みの場合:
--state-reason completed - •重複・対象不在・意図不明の場合:
--state-reason not_planned
- •実装済み・解決済みの場合:
- •以降の構造的判定はスキップ
対応必要と判定した場合:
- •次の手順（構造的判定）へ進む
- •
各Issueの構造的判定 以下の基準で story/task を判定する。
ラベルの定義:
- •
storyラベルは、ストーリー（親Issue）にのみ付与する- •ユーザーの要望やユーザーに提供する価値が記載されているIssue（WHYが中心）
- •
taskラベルは、タスクIssue（サブIssue）にのみ付与する- •作業者に依頼できるくらいに実装方法が具体化されているIssue（HOWが中心）
構造的な判定基準:
story候補の条件:
- •サブIssueが1つ以上存在する
- •本文がユーザーストーリー形式（「〜として、〜したい」等）で記述されている
- •受け入れ条件セクションがある
task候補の条件: サブIssueを持たないIssueであり、かつ以下のいずれかの条件を満たすもの:
- •本文に「親ストーリー」セクションまたは親Issueへの参照（
#数字形式でのリンク）がある - •具体的な実装内容・完了条件が記述されている
判定結果:
- •story候補のみ満たす →
storyラベル付与、taskラベル削除 - •task候補のみ満たす →
taskラベル付与、storyラベル削除 - •両方満たす（矛盾） → 両ラベル削除、エラー表示
- •どちらも満たさない → ラベル変更なし、判定不能を報告
- •
- •
ラベル操作
- •
githubスキル（issue-update.sh）の--add-label/--remove-labelを使用 - •story/task以外のラベルは一切変更しない
- •既に正しいラベルが付与されている場合は変更不要
- •
- •
結果報告 処理結果を一覧形式でユーザーに報告する:
- •Issue番号、タイトル、トリアージ結果（対応必要/対応不要）
- •対応不要の場合: クローズ理由とstate-reason
- •対応必要の場合: 構造的判定結果（story/task/矛盾/判定不能）と実行したラベル操作