shepherd-pr

PR レビュー

PR のコメントとビルドステータスを自律的にレビューし、高い確信度（80% 以上）で対応できるものは解決し、それ以外は人間によるレビューのためにフラグを立てます。

ワークフロー

注: このリポジトリでは node 24 を使用する必要があります。コマンドを実行する前に nvm を使用して node 24 に切り替えてください:

nvm use 24

1. コンテキストの収集

# Get PR number for current branch
gh pr view --json number,headRefName,url

# Get review threads with resolution status
gh api graphql -f query='
  query($owner: String!, $repo: String!, $number: Int!) {
    repository(owner: $owner, name: $repo) {
      pullRequest(number: $number) {
        reviewThreads(first: 100) {
          nodes {
            id
            isResolved
            comments(first: 50) {
              nodes {
                body
                path
                line
                author { login }
                createdAt
                databaseId
              }
            }
          }
        }
      }
    }
  }
'

未解決のスレッドのみに絞り込みます。

2. 各未解決コメントのトリアージ

参照されているコードを読み、調査します。次のように分類します:

A. 誤検出 / すでに解決済み — 現在のコードでは問題がもはや存在しない。

• 特定のコードやコミットを引用して、その理由を説明する返信をします。
• スレッドを解決します。

B. 些細な修正（確信度 80% 以上） — 明白で機械的な修正。設計上の判断や意見の相違を含まないもの。例: 誤字、欠落した null チェック、誤った変数名、オフバイワン、欠落したインポート。

• 修正を行います。
• 変更内容を説明する返信をします。
• スレッドを解決します。

C. 人間の入力が必要（確信度 80% 未満） — 設計上の質問、重要なリファクタリング、または曖昧な修正。

• 解決しないでください。
• セッション終了時のサマリーに追加します。

3. スレッドへの返信と解決

コメントへの返信:

gh api repos/{owner}/{repo}/pulls/{number}/comments/{comment_id}/replies \
  -f body="<your reply>"

スレッドの解決:

gh api graphql -f query='
  mutation($threadId: ID!) {
    resolveReviewThread(input: {threadId: $threadId}) {
      thread { isResolved }
    }
  }
' -f threadId="$THREAD_ID"

常に修正をプッシュし、次に返信し、次に関連するスレッドを解決します（この順序で）。

4. ビルドステータスの確認

gh pr checks --json name,status,conclusion

カテゴリ別に失敗を調査します:

Lint エラー — pnpm lint-current を実行します。機械的なもの（フォーマット、インポート順、未使用変数）であれば修正します。Lint ルール自体が疑わしい場合はフラグを立てます。

型エラー — リポジトリルートから pnpm typecheck を実行します。単純な型の不一致は修正します。修正にアーキテクチャ上の判断が必要な場合はフラグを立てます。

ユニットテストの失敗 — 該当するワークスペースで pnpm test run を実行します。意図的なコード変更によりテストの期待値が明らかに古くなっている場合は修正します。失敗が実際のバグや設計上の懸念を明らかにしている場合はフラグを立てます。

E2E スナップショットの失敗 — PR のコード変更が視覚的な差異を_引き起こすべき_かどうかを判断します:

• はいの場合（UI の変更、スタイルの更新）: update-snapshots ラベルを追加して自動更新ワークフローをトリガーします:

  gh pr edit --add-label "update-snapshots"
  

• いいえの場合: 意図しないリグレッションとして人間のレビューのためにフラグを立てます。

不可解な / 予期しない失敗 — 修正を試みないでください。エラー出力とともに人間のレビューのためにフラグを立てます。

5. 修正のコミットとプッシュ

git add <specific files>
git commit -m "Address PR review feedback

- <summary of changes>"
git push

特定のファイルのみをステージングします。force push は決してしないでください。git add -A は決して使用しないでください。

6. セッション終了時のサマリー

常に次のように終了します:

## PR review summary

### Resolved
- <thread>: <what was done>

### Fixed
- <description of fix>

### Needs your input
- <thread>: <why it needs human judgment>

### Build status
- <status of each check, any actions taken>

空のセクションは省略します。

ガイドライン

• 保守的なしきい値: 修正が正しく、議論の余地がないと 80% 以上確信できる場合にのみ行動します。
• 設計上の質問や意見の相違を提起するコメントは決して解決しないでください。
• まず返信せずに解決しないでください。
• コメントが誤検出であると結論付ける前に、実際のコードを読んでください。
• 修正が型（pnpm typecheck）や Lint（pnpm lint-current）を壊さないことを確認してください。
• 変更が明らかに意図的なものでない限り、テストの期待値を変更しないでください。