一键导入
pr-comment
PRレビュー指摘をGitHubインラインコメントとして投稿する
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
PRレビュー指摘をGitHubインラインコメントとして投稿する
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | pr-comment |
| description | PRレビュー指摘をGitHubインラインコメントとして投稿する |
| argument-hint | <PR番号 or URL> [--file <comments.md>] |
PRレビュー指摘をGitHub PRインラインコメントとして投稿するグローバルスキル。
/pr-reviewの後段として独立起動する。
/pr-comment #824
/pr-comment https://github.com/o/r/pull/824
/pr-comment 824 --file /tmp/pr-824-comments.md
--file <path>: コメント記載の.mdファイル。省略時は会話コンテキストからmd生成。## 1. `src/features/calls/validations.ts:101-108`
[must] 担当NGダイアログのsubmitが壊れる可能性があります。
`personInChargeDialogSchema`の`needs_*`が`.optional()`なしの必須オブジェクトなのに、
PRでFormGroupを全削除してるので、フィールド未登録→zodResolverが`Required`エラーかと。
最小修正: `needs_*`を`.optional()`にするとよいかもです。
## 2. `src/features/deals/field-reconciliation.test.ts:24`
[should] 型レベル保証が失われていそうです。
## N. \filepath:line`または## N. `filepath:line-line``[must] / [should] / [nit] / [question] / [suggestion]```ts or ```suggestion(GitHub suggested changes)zodResolverが ← 正)短文(1〜2文、[nit]など軽い指摘)→ カジュアル寄り:
〜かもです。〜いいかもです!〜の方がいいかもです。〜良さそうです。〜で統一して行ければと…!〜でお願いします!長文(問題→原因→修正案、[must]/[should]など重い指摘)→ 丁寧寄り:
〜かなと思いました。 / 〜かなとおもいました。〜かと。〜気がします。〜可能性があります。〜よいかもです。〜いいのかなと。〜安心かもです。〜推奨します。(具体的修正案のとき)[severity] + 要約1文**差分補足**(指摘ではありません)で明示Phase 1 PR情報取得 → Phase 2 コメント生成/パース → Phase 3 diff検証&リダイレクト
→ Phase 4 ユーザー確認 → Phase 5 GitHub API投稿 → Phase 6 結果レポート
# PR番号抽出
PR_NUM=$(echo "$ARG" | grep -oE '[0-9]+$')
# メタデータ取得
gh pr view "$PR_NUM" --json number,headRefOid,url
# owner/repo取得
gh repo view --json nameWithOwner -q '.nameWithOwner'
# diff取得(hunk範囲検証用)
gh pr diff "$PR_NUM" > /tmp/pr-${PR_NUM}.diff
# 変更ファイル一覧
gh pr view "$PR_NUM" --json files --jq '.files[].path'
取得する情報:
headRefOid → commit_id(コメント投稿に必須)--file指定あり(編集済み再投稿):
--file指定なし(新規生成):
/pr-review出力など)からコメントを構成/tmp/pr-${PR_NUM}-comments.md に書き出しどちらの場合も、投稿前に必ず一時mdを生成する。
パース結果を以下の構造に変換:
{ path: string, line: number, endLine?: number, severity: string, body: string }[]
各コメントについて順に検証:
Step 1: ファイルがdiffに含まれるか
grepして、diff外ファイルを参照しているdiff内ファイルを特定(実ファイル: \src/features/calls/validations.ts:101-108`)`Step 2: 行番号がdiff hunk範囲内か
@@ -old,count +new_start,new_count @@ をパースnew_start 〜 new_start + new_count - 1 がRIGHT sideの有効範囲Step 3: side判定
"side": "RIGHT"(変更後ファイル)4.1 一時mdファイルの書き出し(Phase 2で未生成の場合)
検証・リダイレクト結果を反映した最終版を /tmp/pr-${PR_NUM}-comments.md に書き出し。
4.2 eventの自動提案
| 条件 | 提案するevent |
|---|---|
[must]が1件以上 | REQUEST_CHANGES |
指摘あり、[must]なし | COMMENT |
| 指摘0件 | APPROVE |
4.3 AskUserQuestionで確認
選択肢:
eventの変更もここで可能にする(例: 「REQUEST_CHANGESじゃなくてCOMMENTで」)。
gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews \
--method POST \
--input /tmp/pr-${PR_NUM}-review-payload.json
payload構造:
{
"commit_id": "<headRefOid>",
"event": "COMMENT",
"body": "<bodyに回したコメントがあればここ。なければ空文字>",
"comments": [
{
"path": "src/components/domain/calls/call-person-in-charge-dialog.tsx",
"line": 46,
"side": "RIGHT",
"body": "(実ファイル: `src/features/calls/validations.ts:101-108`)\n\n[must] 担当NGダイアログの..."
}
]
}
投稿結果をテーブルで報告:
| # | Severity | ファイル | 投稿先 |
|---|----------|----------|--------|
| 1 | [must] | calls/validations.ts:101-108 | call-person-in-charge-dialog.tsx:46 (リダイレクト) |
| 2 | [should] | field-reconciliation.test.ts:24 | インライン :24 |
| 3 | [nit] | validations.test.ts:385 | インライン :385 |
| 4 | [should] | use-handle-call-details.ts:430 | レビュー本文 (diff外) |
| 制約 | 対処 |
|---|---|
| インラインコメントはdiff内ファイルのhunk範囲内のみ | Phase 3で事前検証 |
| diff外ファイル → 422 | import逆引きリダイレクト or body移動 |
| hunk外行番号 → 422 | body移動 |
| commit_idはPRのHEAD必須 | headRefOidを使う |
| エラー | 対応 |
|---|---|
| 422 Unprocessable Entity | Phase 3検証漏れ → 該当コメントをbodyに回して再投稿 |
| 404 Not Found | commit_id古い or PR不存在 → PR情報再取得 |
| 403 Forbidden | 権限不足 → gh auth status確認を案内 |
| パース失敗 | .mdフォーマット不正 → フォーマット例を提示 |
GitHub PR を worktree 隔離でレビューする。仕様書 (CLAUDE.md / docs / spec 等) を参照し、 codex が利用可能なら並列に独立レビューを依頼、両者の指摘を統合一本化。 最終出力前にファクトチェックとPRスコープチェックの2パスを自己実施。 トリガー: `/pr-review` (明示起動のみ)
要件定義書・仕様書・実装計画書を自動生成するスキル。 要件には REQ-{SCOPE}-{SEQ} 形式のIDを付与し、実装計画は要件IDに基づいて作成。 docs/requirements/、docs/specifications/、docs/implementation/ に複数ファイルとして出力する。 トリガー: "plan-docs", "/plan-docs" 使用場面: プロジェクトの要件定義・仕様策定・実装計画の作成が必要な時。新規プロジェクト開始時や機能追加の計画時。
Codex CLI(OpenAI)を使用してコードや文言について相談・レビューを行う。 トリガー: "codex", "codexと相談", "codexに聞いて", "コードレビュー", "レビューして" 使用場面: (1) 文言・メッセージの検討、(2) コードレビュー、(3) 設計の相談、(4) バグ調査、(5) 解消困難な問題の調査
Google の Gemini CLI を、コード生成・レビュー・分析・Web 調査のための強力な補助ツールとして活用する。別の AI の視点、Google 検索による最新情報、コードベースアーキテクチャ分析、並列コード生成が有益なタスクに使用する。ユーザーが明示的に Gemini の操作を要求した場合にも使用する。
実装・計画・作業を開始する前に、曖昧な点を残さずユーザーに確認を取るためのキックオフニュアンス。 git管理下であればブランチ戦略、コミット粒度、PR作成の有無・タイミング、スコープを必ず事前確認する。 トリガー: "実装", "実装して", "計画", "計画して", "作業開始", "着手", "やって", "お願い", "キックオフ", "kickoff", "/kickoff" 使用場面: コード変更・新規実装・リファクタ・修正・調査から実装に移る時など、「手を動かし始める前」に毎回使う。