メニュー
GitHub Issueに対して現在のブランチのローカル実装をレビューする
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
GitHub Issueを親Issueとしてタスク分解し、子Issueを作成する。
変数や関数の命名候補を複数提案し、それぞれのニュアンスを解説する。
piコーディングエージェントのextensionを作成する
与えられた指示に対して、コードベースを探索してリポジトリ構造と関連箇所を把握し、開発者と一問一答で実装方針・設計・タスク分解を固める。実装前の壁打ちやPlanモード的な相談に使う。
TDD（テスト駆動開発）のRed-Green-Refactorサイクルに従って機能を実装する
GitHub Issue番号と任意の分岐元ブランチ名を受け取り、実装方針策定・ブランチ作成・TDD実装・コードレビュー修正ループを一連で実行する
SOC 職業分類に基づく
| name | review-local |
| description | GitHub Issueに対して現在のブランチのローカル実装をレビューする |
| argument-hint | <Issue番号> [分岐元ブランチ] |
| allowed-tools | Skill(fallow-review), Read, Glob, Grep, Bash(gh issue view:*), Bash(gh issue list:*), Bash(gh repo view:*), Bash(git rev-parse:*), Bash(git log:*), Bash(git diff:*) |
$ARGUMENTS を空白区切りの位置引数として解釈する。第1引数は対象Issue番号、第2引数は任意の分岐元ブランチ名である。
gh issue view <Issue番号> --json number,title,body,labels,comments,state,url を実行して、対象Issueの番号・タイトル・本文・ラベル・コメント・状態・URLを取得する。
GitHub上のIssue relationshipでParent issue等が設定されているか確認するため、gh issue list --state all --search "#<Issue番号>" --json number,parent,subIssues,subIssuesSummary,blocking,blockedBy --jq '.[] | select(.number == <Issue番号>)' を実行する。Parent issueが存在する場合は、gh issue view <親Issue番号またはURL> --json number,title,body,labels,comments,state,url で親Issueの内容も取得する。
以降のレビューでは、対象Issueの要件に加えて、親Issueの目的・制約・スコープも判断材料として参照する。
第2引数に分岐元ブランチ名が指定されている場合は、デフォルトブランチではなくそのブランチを分岐元として扱う。
第2引数が指定されていない場合は、git rev-parse --abbrev-ref @{upstream} で現在のブランチの追跡ブランチを取得する。
追跡ブランチが設定されていない場合のみ、gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name' でデフォルトブランチ名を取得し、origin/<デフォルトブランチ名> を分岐元とする。
git log --oneline <分岐元>..HEAD でコミット一覧を確認し、git diff <分岐元>...HEAD で分岐元からのコミット済み差分を取得。
git diff HEAD でステージ済み・未ステージの両方を含む未コミット差分を取得。未コミットの変更がある場合は、レビュー結果内で [未コミット] と明示すること。
以下のいずれかに該当する場合はTS/JSプロジェクトとして扱う。
package.json、tsconfig.json、jsconfig.jsonのいずれかが存在する.ts、.tsx、.js、.jsx、.mjs、.cjsのいずれかが含まれるTS/JSプロジェクトの場合は、Skillツールを使用して fallow-review スキルを呼び出す。argsにはステップ2.1で特定した 分岐元ref のみを渡す。
fallow-reviewの結果は意味的レビューとは別の構造チェックとして扱い、指摘事項・総合判定に反映する。fallow-reviewが要修正の場合はreview-localの総合判定も原則要修正、要議論の場合は原則要議論以上として扱う。ただし、fallow-reviewの懸念が今回の差分に関係しないことを差分から明確に判断できる場合は、その理由を明記したうえで判定を調整してよい。
対象Issueおよび親Issueの要件、実装差分、TS/JSプロジェクトの場合はfallow-reviewの結果を照らし合わせて、以下の観点でレビューする:
以下のフォーマットで結果をまとめる:
対象Issueの要件に対する実装の全体的な評価を1〜2文で。親Issueを参照した場合は、その観点での評価も含めること。
対象Issueの各要件について、対応状況を一覧で示す。親Issueを参照した場合は、親Issue由来の制約・スコープとの整合性も示す。
問題や改善提案があれば、該当ファイル・行番号とともに具体的に記載。
TS/JSプロジェクトとしてfallow-reviewを実行した場合は、サマリー・構造的な懸念・判定を要約して記載する。実行しなかった場合は、その理由を簡潔に記載する。
LGTM / 要修正 / 要議論 のいずれかで判定。