load-pr-comments

未解決の PR レビューコメントを並列タスクとして読み込む

未解決の PR レビュースレッドのみを読み込み、.specs/comments/*.md の下にグループ化した Markdown タスクファイルとして書き換えます。各ファイルは、別々のエージェントが重複なく安全に実装できる内容にします。

重要なガイドライン

• 解決済み状態が false のスレッドのみを必ず読み込んでください。解決済みのスレッドはスキップします。
• 各コメントは、要約ではなく実行可能なタスク要件として必ず書き換えてください。内容（コードの提案、正確な指示）はそのまま保ってください。
• GitHub への投稿、返信、変更は絶対に行わないでください。このスキルは API に対して読み取り専用です。
• 各ファイルが個別に実装でき、ファイル間で重複がないように、コメントをグループ化してください。

ステップ 0：利用可能なツールを確認する

1. GitHub CLI がインストールされ、認証済みかどうかを確認します。

   gh auth status
   

2. GitHub MCP サーバーが利用可能か確認します。

   mcp__MCP_DOCKER__pull_request_read
   

   または、直接インストールされている場合は MCP_DOCKER プレフィックスのない同等のコマンドを使います。

• 両方が利用可能な場合は、リポジトリへのアクセス権が十分にある方を使います。
• GitHub MCP サーバーが利用可能でも構造が異なる場合は、想定される構造に合うように調整します。
• どちらも利用できない場合は、公開リポジトリであれば curl で直接読み込んでみてください。プライベートリポジトリの場合は、GitHub CLI または GitHub MCP サーバーをインストールするようユーザーに依頼します。
• MCP サーバーがインストールされておらず、GitHub CLI はインストールされているものの未認証の場合は、認証のために gh auth login を実行するようユーザーに依頼します。

ステップ 1：対象の PR を特定する

• 明示的に指定された PR 引数は、常に現在のブランチからの特定より優先されます。PR 番号または URL が渡された場合は、それを使います（https://github.com/{owner}/{repo}/pull/{n} のような URL からは番号 {n} を取得します）。現在のブランチは確認しないでください。
• それ以外の場合は、現在のブランチの PR を既定として使用します。

gh pr view --json number,url,headRefName   # current branch's PR

• リポジトリのオーナー名／名前を解決します：gh repo view --json owner,name。
• ブランチに PR が存在しない場合、gh pr view は「no pull requests found」というエラーになります。その場合は処理を停止し、ブランチに関連付けられた PR がないことを報告して、PR 番号または URL を尋ねてください。

ステップ 2：未解決のコメントを取得する

解決済み／未解決は GraphQL の reviewThreads { isResolved } の概念です。REST の /pulls/{n}/comments エンドポイントでは公開されません。以下のいずれかの方法を使用します。第一候補が利用できない場合は、もう一方に切り替えてください。

第一候補：gh CLI（GraphQL）

jq 内で isResolved == false をフィルターします。

gh api graphql -f query='
query($owner:String!,$repo:String!,$pr:Int!){
  repository(owner:$owner,name:$repo){
    pullRequest(number:$pr){
      reviewThreads(first:100){
        nodes {
          isResolved
          isOutdated
          path
          line
          startLine
          originalLine
          comments(first:50){
            nodes { author{login} body diffHunk url }
          }
        }
      }
    }
  }
}' -F owner=OWNER -F repo=REPO -F pr=PR_NUMBER \
  --jq '[.data.repository.pullRequest.reviewThreads.nodes[]
         | select(.isResolved==false)
         | {path, isOutdated,
            line: (.line // .startLine // .originalLine),
            comments: [.comments.nodes[]
             | {author: .author.login, url, body, diffHunk}]}]'

これは、各未解決スレッドについて、ファイルの path、isOutdated フラグ、使用可能な line、および順序付きのコメント（author、body、permalink の url、diffHunk）を返します。

重要：古いスレッドでは line が null になります（diff が移動しているためです）。上記の jq ではすでに line // startLine // originalLine にフォールバックするため、アンカーが存在する場合に line が null になることはありません。この3つすべてが null の場合は、テンプレート内で :<line> の部分を省略してください。path:null と表示してはいけません。

フォールバック：GitHub MCP

GitHub MCP サーバー（MCP_DOCKER）が利用可能な場合は、method: "get_review_comments" を指定して mcp__MCP_DOCKER__pull_request_read ツールを使用します。

mcp__MCP_DOCKER__pull_request_read
  method: "get_review_comments"
  owner: "OWNER"
  repo: "REPO"
  pullNumber: PR_NUMBER
  perPage: 100

このツールは review_threads[] を返します。各要素には is_resolved、is_outdated、is_collapsed（すべて snake_case。ツールの応答で確認済み）と、comments[]（body、path、author、html_url）が含まれます。is_resolved が false のスレッドのみを残してください。MCP のコメントオブジェクトには path はありますが行番号はないため、場所のアンカーとして html_url を使用します。pageInfo.hasNextPage が true の間は、after: <endCursor> を指定してページネーションしてください。

Step 3: グループ化してタスクに書き換える

未解決のスレッドを、並行して作業するエージェント向けの、目的を絞ったタスクファイルに変換します。

グループ化する前に、まず重複を排除します。同じ path の同じ行または重複する行に対して、2つ以上のスレッドが同じ変更を求めている場合や、同一の修正案が含まれている場合は、1つの要件にまとめます。重複したスレッドごとに別々の項目を出力してはいけません。繰り返しの細かな提案が集まりやすい nitpick ファイルでは、特に重要です。

スレッドごとの書き換えルール：

• 会話の経緯や投稿者名は削除します。会話の記録ではなく、タスクを出力します。
• 人間のレビュアーがフィードバックを残している場合は、その内容を要件として記述します。
• ボット／AI による提案のみがある場合は、その修正案を要件として記述します（Claude、CodeRabbit、Copilot など）。
• 内容を保ちます。コードブロック、差分案、正確な文言を要約して省略してはいけません。
• 背景を追加します。問題の簡潔な説明と、利用できる場合はファイル／行へのリンク（コメントの url／html_url と path:line）を記載します。line が null（古くなった／位置を特定できないスレッド）の場合は、:line の部分を付けずに path だけを記載し、古くなっていることを注記します。

変更前／変更後（「要約せずタスクに書き換える」を徹底）：

• 元のスレッド（ボット）：「commands is incorrect, real commands is more like /add-task /plan-task /implement-task」
• タスク要件：「- [ ] 記載されているコマンドを正しいものに置き換えます：/add-task、/plan-task、/implement-task」（会話の経緯は削除しますが、提案はそのまま残します。「コマンドを修正する」のように要約してはいけません）

グループ化のルール：

• ファイル単位または機能単位でグループ化し、2人のエージェントが同じ領域を変更しないようにします。競合や作業の重複を避けてください。
• 1つのコメントを複数のファイルに重複して記載してはいけません。
• 細かな指摘や些細な1行の変更は、1つのファイル（例：nitpicks.md）にまとめます。
• ファイルは合計5個以下にします。関係のない変更を過度にまとめてはいけません。各ファイルは、独立して実施できる、目的を1つに絞った作業単位にしてください。

Step 4: .gitignore の処理

生成されるコメントファイルが無視されるようにします。これは冪等な処理です。エントリが存在しない場合にのみ追加し、>> によって .gitignore が存在しない場合は作成されます。

grep -qF '.specs/comments/*.md' .gitignore 2>/dev/null || printf '\n.specs/comments/*.md\n' >> .gitignore

Step 5: ファイルを書き込む

mkdir -p .specs/comments

各グループを次のテンプレートを使って .specs/comments/<kebab-topic>.md として書き込みます。

# Tasks: <focused topic, e.g. Fix incorrect command names in README-zh>

## <Topic 1>

File: `<path>:<line>` (omit `:<line>` when line is null; append " (outdated)" if isOutdated)
<Issue description for the change>

### Requirements

- [ ] <Reviewer requirement or bot fix suggestion, substance preserved>
- [ ] <Next requirement in this topic>

## <Topic 2>

File: `<path>:<line>` 
<Issue description for the change>

### Requirements

- [ ] <Reviewer requirement or bot fix suggestion, substance preserved>
- [ ] <Next requirement in this topic>

Step 6: 報告

対象の PR（番号と URL）、読み込んだ未解決スレッド数、トピックとともに作成したファイル、およびスキップしたスレッド（解決済み）や発生した制限（例：MCP を利用できない）をまとめて報告します。

エッジケース

状況	対応
現在のブランチに PR がない	gh pr view がエラーになった場合は、その旨を報告して PR 番号／URL を求めます
引数が URL	/pull/ の後に続く末尾の番号を抽出します
未解決スレッドが 0 件	ファイルを作成せず、「未解決のコメントはありません」と報告します
スレッドが 100 件を超える	ページネーションを行います（GraphQL の after カーソル／MCP の after）
MCP を利用できない	gh GraphQL を使用します。どちらも利用できない場合は、制限事項を報告します
解決済みスレッドのみ	すべてスキップし、対応が必要なものはないと報告します