一键导入
pickup-review
AIが編集したコードファイルから人間のインラインレビューマーカー(review-comment:)を抽出し、指摘の意図を整理して議論し、必要な場合だけ修正・マーカー削除まで行う。「レビュー拾って」「コメント拾って」「review-comment対応して」「なぜそうしたか確認して」等の依頼で使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
AIが編集したコードファイルから人間のインラインレビューマーカー(review-comment:)を抽出し、指摘の意図を整理して議論し、必要な場合だけ修正・マーカー削除まで行う。「レビュー拾って」「コメント拾って」「review-comment対応して」「なぜそうしたか確認して」等の依頼で使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 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 | pickup-review |
| description | AIが編集したコードファイルから人間のインラインレビューマーカー(review-comment:)を抽出し、指摘の意図を整理して議論し、必要な場合だけ修正・マーカー削除まで行う。「レビュー拾って」「コメント拾って」「review-comment対応して」「なぜそうしたか確認して」等の依頼で使用。 |
| argument-hint | [path...|--all] |
| allowed-tools | Bash, Read, Edit, Grep, Glob, mcp__acp__Read, mcp__acp__Edit |
| disable-model-invocation | false |
コードファイル内に書かれた review-comment: マーカーを抽出し、各指摘の意図を整理して議論する。必要な場合だけコードを修正し、対応したマーカーを自動で削除する。GitHub PR の inline review コメントに相当するワークフローをローカルで完結させる。
形式: review-comment: <本文>
//, #, --, <!--, ; 等) は問わない。review-comment: を含む行を全て対象にするreview-comment: 行は1つのコメントとして結合する例:
function calculate(x) {
// review-comment: edge caseでマイナス値を考慮して
return x * 2;
}
main との差分ファイルを優先する
git diff --name-only main...HEADgit diff --name-onlygit diff --cached --name-onlygit ls-files --others --exclude-standardmain が存在しない場合は origin/main、master、origin/master の順で利用可能なベースを探す--all 指定時のみ → git ls-files の出力(git追跡ファイル全体)git管理下の追跡ファイルは git grep を優先で使用する。
git grep -n 'review-comment:' -- <scope>
指定パス、未追跡ファイル、または git grep で扱いにくい対象は rg --hidden を使用する。
rg --hidden -n --no-heading 'review-comment:' <scope>
rg が利用不能な場合は Grep ツールへフォールバックreview-comment: マーカーが見つかりませんでした(検索対象: ○件)」と明示してskill終了出力イメージ:
src/foo.ts
#1 L42 edge caseでマイナス値を考慮して
40 | function calculate(x) {
41 | // review-comment: edge caseでマイナス値を考慮して
42 | return x * 2;
...
要修正: 指摘が妥当で、コード変更が必要要議論: 指摘は妥当そうだが、設計判断・トレードオフ・仕様確認が必要説明のみ: 「なぜそうしたのか」を知りたい質問で、すぐに修正すべきではない対応不要: 指摘が誤解、既存制約と矛盾、または変更しない方がよい説明のみ はコード変更案ではなく、該当実装の意図・背景・代替案との比較を説明する対応不要 は単に拒否せず、なぜ変更しない判断が妥当か、必要なら代替コメント案を出す要議論 は確認したい論点を明示し、すぐに編集しない要修正 のみ、具体的な対応案をチャットに出力するreview-comment: が含まれている疑いがあれば「これは文字列内の可能性があります、対応対象から外しますか?」と注記する要議論、説明のみ、対応不要、ユーザーがスキップ判断したマーカーは修正しないコード修正したマーカー、またはユーザーが「説明で解決」「対応不要で解決」と明示したマーカーは自動で削除する。未解決・要議論・スキップ判断したマーカーは残す。
削除方法は行の構造で分岐する:
review-comment: のみ)→ 行ごと削除判定例:
// 行ごと削除されるパターン
// review-comment: マイナス値を考慮して
// マーカー部分のみ削除されるパターン
return x * 2; // review-comment: 戻り値の型を見直して
// ↓
return x * 2;
最後に以下を出力する: