address-github-issue

GitHub の issue を取得し、チームで対応します。

使用方法：

• /address-github-issue 42 — 現在のリポジトリの issue #42 に対応します
• /address-github-issue owner/repo#42 — 指定したリポジトリの issue #42 に対応します
• /address-github-issue https://github.com/owner/repo/issues/42 — URL で指定した issue に対応します

手順：

1. gh CLI が利用可能であることを確認します：

   • gh --version を実行して、インストールされていることを確認します
   • 見つからない場合は処理を中止し、次の内容を表示します：

     ❌ GitHub CLI (`gh`) がインストールされていません。
     次のコマンドでインストールしてください：brew install gh
     その後、次のコマンドで認証してください：gh auth login
     

   • gh auth status を実行して、認証済みであることを確認します
   • 認証されていない場合は処理を中止し、次の内容を表示します：

     ❌ GitHub CLI が認証されていません。
     次のコマンドを実行してください：gh auth login
     

2. $ARGUMENTS から issue の参照情報を解析します：

   • $ARGUMENTS が空の場合は、AskUserQuestion で issue の参照情報を尋ね、情報が提供されるまで処理を中止します。
   • 使用可能な形式：
     • 数字のみ（例：42）→ 現在のリポジトリを使用します
     • owner/repo#42 → リポジトリと番号を指定します
     • GitHub の完全な URL（例：https://github.com/owner/repo/issues/42）→ URL からリポジトリと番号を解析します
   • 数字のみの場合は、gh repo view --json nameWithOwner -q .nameWithOwner で現在のリポジトリを特定します。失敗した場合（GitHub リポジトリ内でない場合）は、次の内容を表示して処理を中止します：

     ❌ GitHub リポジトリを特定できませんでした。
     GitHub リポジトリ内からこのスキルを実行するか、issue の完全な参照情報（例：owner/repo#42）を指定してください。
     

3. issue を取得します：

   • 次を実行します：

     gh issue view <number> --repo <owner/repo> --json number,title,body,labels,assignees,milestone,state,comments,url
     

   • issue が見つからない場合、またはアクセスが拒否された場合は、gh のエラーメッセージを表示して処理を中止します。
   • JSON 出力を解析し、次の情報を抽出します：
     • title、body、labels、state、url
     • comments 配列（各項目には author.login と body が含まれます）

4. issue を分析します：

   • タイトル、本文、すべてのコメントを十分に確認します。
   • issue の種類を特定します：
     • バグ — 何かが壊れている状態です。bug、defect、regression などのラベルが付いている場合があります
     • 機能 — 新しい機能です。enhancement、feature request などのラベルが付いている場合があります
     • 雑務／メンテナンス — 技術的負債、リファクタリング、CI、ドキュメントなどです。chore、docs、refactor などのラベルが付いている場合があります
     • 質問／調査 — コーディングの前に調査が必要です
   • 範囲と複雑さを特定します：
     • シンプル（開発者 1 人）— 個別の修正または小規模な追加で、変更対象が 2 ファイル以下、API やスキーマの変更がないもの
     • 中程度（開発者 2 人）— 複数の要素が関わる中規模の機能またはバグで、フロントエンドとバックエンドを個別に変更する場合があります
     • 複雑（開発者 3 人）— 大規模な機能、アーキテクチャの変更、複数の領域にまたがる課題、または複数の独立した作業ストリームを含むもの
   • 要件を明確にするため、PM が確認すべき曖昧な点や不足している情報を記録します。

5. チーム構成を決定します：

   • 必ず PM を 1 人起動します。
   • 上記の複雑さの評価に基づき、開発者を 1 人、2 人、または 3 人起動します。
   • このスキルではデザイナーやテスターは起動しません（開発者が実装にテストを含めることを想定しています）。

6. チームを作成します：

   • issue のタイトルまたは番号から作成した短いケバブケース名（例：issue-42、fix-login-crash、add-dark-mode）を使って TeamCreate を実行します。
   • エージェントを起動する前に、各役割につき 1 つのタスクを TaskCreate で作成します：
     • PM のタスク：「issue # の要件と受け入れ基準を作成する」
     • 開発者ごとのタスク：「issue # の を実装する」

7. PM を起動します（subagent_type: general-purpose）：

   • 次の情報を提供します：
     • Issue の全内容（タイトル、本文、すべてのコメント、URL）
     • Issue の種類と複雑さの評価
     • チーム名
   • PM の担当業務：
     • すべてのコメントを含め、Issue を十分に読み込みます
     • コメントとコードベースに関する知識を使って曖昧さを解消し、Issue に対応する詳細な要件と受け入れ条件を作成します
     • 要件を次の形式で構成します：

       ## Issue #<number>: <title>
       **Type:** <Bug / Feature / Chore> | **URL:** <url>
       
       ## Context
       <Issue の概要と重要性を簡潔にまとめます>
       
       ## Requirements
       <具体的でテスト可能な要件の番号付きリスト>
       
       ## Acceptance Criteria
       <Issue の解決時に満たされている必要がある条件のチェックリスト>
       
       ## Developer Workstreams
       <複数の開発者がいる場合：各ワークストリームの範囲と、合意が必要な共有インターフェースや契約を明確に説明します>
       
       ## Out of Scope
       <この Issue の対象外として明示されている事項>
       

     • プロジェクトのロアファイル（LORE.md、docs/lore.md、.agent/lore.md など）があるか確認し、この Issue によって生じる関連情報を追加します
     • TaskUpdate を使ってタスクを完了としてマークします
     • 完了したらチームリードにメッセージを送ります

8. PM の完了を待ち、完了したタスクまたは PM のメッセージから要件を取得します。

9. 開発者を起動します（subagent_type: general-purpose）。ワークストリームごとに 1 人ずつ、並行して起動します：

   • 各開発者に次の情報を提供します：
     • 元の Issue の内容（タイトル、本文、コメント、URL）
     • PM の要件ドキュメント
     • 各自の担当ワークストリームの範囲（複数の開発者がいる場合）
     • Issue の種類（コンテキストとして：バグ修正 → リグレッションテストを作成、機能追加 → 単体テスト／結合テストを作成、など）
   • 各開発者の担当業務：
     • 関連するコードベースの部分を調査します
     • 担当ワークストリームで必要な変更を実装します
     • 変更をカバーするテストを作成します（最低限、単体テスト。該当する場合は結合テストも作成します）
     • TaskUpdate を使ってタスクを完了としてマークします
     • 完了したらチームリードにメッセージを送ります

10. すべての開発者の完了を待ちます。

11. 競合がないか確認します：

    • 複数の開発者を起動した場合、複数のエージェントが同じファイルを変更していないか確認します
    • 競合がある場合は、両方の変更内容を読み、適切に統合して解決します
    • 簡易チェックを実行し、すべての変更を適用した後にコードベースがコンパイルでき、リントに問題がないことを確認します（利用可能であれば、プロジェクト既存のリント／ビルドスクリプトを使用します）

12. ユーザーに最終的な概要を提示します：

    ## Issue #<number> を解決しました
    
    **Issue：** <title>
    **URL：** <url>
    
    ### 実施内容
    - <変更内容の概要>
    
    ### 追加したテスト
    - <追加または更新したテストファイルの一覧>
    
    ### 開発者
    - <開発者 1>：<実装内容>
    - <開発者 2>：<実装内容>（該当する場合）
    
    ### 推奨される次のステップ
    - `/review-changes` で変更内容をレビューする
    - `/create-pr` で PR を作成する
    - `gh issue develop <number> --repo <owner/repo>` で PR を GitHub の Issue にリンクする
    

13. チームを適切に終了します：

    • SendMessage を使って各チームメイトに shutdown_request を送ります
    • 全員の確認後、TeamDelete を呼び出します