Menu
Pull Requestを客観的に分析・解説する。PR内容、コメント、技術的妥当性を評価し、忖度なしで総合的な意見を提示する。設計原則との整合性もチェックし、代替案やトレードオフを明示する。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
tmuxセッション内で実際のNeovimを起動し、send-keys / capture-pane で操作・観察してデバッグする。 Neovimの起動確認、プラグインエラーの調査、checkhealthの確認、設定変更の動作確認、 「nvimをデバッグして」「起動確認して」「checkhealth見て」などのリクエストで使用する。 Agentがnvimを直接実行する必要が生じた場合も、必ずこのスキルの手順を使うこと。
AIとの会話を、ユーザーの思考メモ(Self)も含めてGitHub IssueまたはPull Requestにコメントとして追加する実験版。手動で呼び出して使用。
タスクについて詳細に調査し、構造化されたまとめを出力する。ultrathinkモードで深く考察し、背景、期限、過去の対応方法、確認事項を調査。すべての情報に出典リンクを明記し、推測は必ず明示する。
会話文脈から GitHub issue を作成する。「issueを作って」「issue立てて」等のリクエストで使用。本文は「背景 / やりたいこと / 配慮してほしいこと」の3セクション構成。「背景・やりたいこと」は背景と What(何をやりたいか)に集中し How(実装方法)は書かない。「配慮してほしいこと」は任意(省略可)で制約・要望を書く。
AIとの会話をまとめてGitHub IssueまたはPull Requestにコメントとして追加する。手動で呼び出して使用。
AI Agentの説明で理解できない部分を、前提知識なしで噛み砕いて説明する。会話中にその場で呼び出して使う。用語の定義と、なぜそれが重要かを中心に解説する。
| name | explain-pr |
| description | Pull Requestを客観的に分析・解説する。PR内容、コメント、技術的妥当性を評価し、忖度なしで総合的な意見を提示する。設計原則との整合性もチェックし、代替案やトレードオフを明示する。 |
| argument-hint | [PR番号またはURL] [--all] |
| allowed-tools | Bash, Read, mcp__acp__Read |
| disable-model-invocation | false |
Pull Request（PR）について、客観的に分析・解説します。
引数は [PR番号またはURL] [--all] の形式で受け取る。
--all なし）: 未resolveのレビューコメントのみを対象に分析する--all を含む場合: resolve状態に関わらず、すべてのコメントを対象に分析する冒頭で対象モードを明示する。
モード: 未resolveのみ / 全件 ( --all )
GitHub REST API はレビュースレッドのresolve状態を返さないため、resolve状態を含めて取得するには GraphQL を使う。
# {owner}, {repo}, {number} を置き換える
gh api graphql -f query='
query($owner: String!, $repo: String!, $number: Int!) {
repository(owner: $owner, name: $repo) {
pullRequest(number: $number) {
reviewThreads(first: 100) {
nodes {
isResolved
isOutdated
path
comments(first: 50) {
nodes {
databaseId
author { login }
body
path
line
originalLine
diffHunk
createdAt
}
}
}
}
}
}
}' -F owner={owner} -F repo={repo} -F number={number}
一般コメント（コードに紐づかない issue comments）は gh pr view {number} --json comments で取得する。一般コメントには resolve 概念がないため、モードに関わらず常に全件を扱う。
reviewThreads.nodes[] のうち isResolved == false のスレッドのみ採用--all: reviewThreads.nodes[] のすべてを採用し、各コメントに resolved=true/false を併記する採用したレビュースレッドに含まれる各コメントを「ステップ2: コードに紐づくコメント」のテンプレートに流し込む。
[変更の要約]
各コメントについて：
スレッド状態： resolved=true/false （--all モード時のみ表示。デフォルトモードでは全件未resolveなので省略）
コメント内容：
[元のコメント全文]
該当コード：
[コメントが指している部分のコード]
コメントの意図： [このコメントは何を指摘しているか]
わかりづらい部分の補足： [専門用語、暗黙の前提、背景知識などを補足]
客観的な評価：
コメント内容：
[元のコメント全文]
コメントの意図： [何について言及しているか]
補足説明： [文脈や背景の説明]
客観的な評価：
各コメントについて、以下の観点で評価：
指摘内容： [...]
技術的妥当性：
理由： [なぜそう評価するか]
代替案： [もし別のアプローチがあれば]
私の意見： [忖度なしの客観的な考え]
指摘内容： [...]
設計原則との整合性：
私の意見： [設計判断として適切か、他の選択肢はあるか]
コメントを理解する上で必要な背景知識：
評価： 適切/要改善/要大幅修正
理由： [...]
推奨対応： [...]
各コメントへの総合的な意見：
| コメント | resolved | 妥当性 | 重要度 | 対応推奨 | 理由 |
|---|---|---|---|---|---|
| [ID] | true/false | ✅/⚠️/❌ | 高/中/低 | 必須/推奨/任意 | [...] |
resolved 列はデフォルトモードでは全て false になるので省略可。--all モード時のみ表示する。
私が考える最適解： [複数の選択肢がある場合、どれが最適と考えるか]
理由：
トレードオフ：