メニュー
PR descriptionと最新のコード差分を比較し、メソッド名・テスト件数・シグネチャ・検証ケースなど「事実」に基づく記述のズレを検出して同期する。リファクタや review 対応で description が陳腐化したときに使用。「PR description を同期」「PR の本文を最新コードに合わせて」「ディスクリプション差分発生時に同期」「sync PR description」等のリクエストで起動する。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
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の説明で理解できない部分を、前提知識なしで噛み砕いて説明する。会話中にその場で呼び出して使う。用語の定義と、なぜそれが重要かを中心に解説する。
SOC 職業分類に基づく
| name | sync-pr-description |
| description | PR descriptionと最新のコード差分を比較し、メソッド名・テスト件数・シグネチャ・検証ケースなど「事実」に基づく記述のズレを検出して同期する。リファクタや review 対応で description が陳腐化したときに使用。「PR description を同期」「PR の本文を最新コードに合わせて」「ディスクリプション差分発生時に同期」「sync PR description」等のリクエストで起動する。 |
| argument-hint | [<pr-number-or-url>] |
| allowed-tools | Bash, Read, Edit, Grep, Glob |
| disable-model-invocation | false |
PR description と最新のコード差分を突き合わせ、追加コミット (review 対応、refactor、テスト削除、メソッドリネーム等) で陳腐化した記述を検出し、現状に合わせて修正する。PR 作成時には正確だった description が後から事実とズレるのを防ぐ。
以下のいずれかの言い回しで起動する:
gh pr view --json number,headRefName,url以下を並列で取得する:
# PR description をローカルに保存 (Edit ツールで操作するため)
gh pr view <num> --json body --jq .body > /tmp/pr-sync-body.md
# PR のコミット履歴 (description との対応関係を見るため)
gh pr view <num> --json commits --jq '.commits[] | .messageHeadline'
# 変更ファイル一覧
gh pr view <num> --json files --jq '.files[].path'
description 内で「事実として書かれた記述」を抽出し、最新のコードと照合する。確認する観点は以下:
description 内のバッククォートで囲まれた識別子 (MethodName, ClassName::method, service_id 等) を抽出し、コードベースで存在を確認する。
git log --all --oneline -S '<旧識別子>' -- <該当ファイル> で rename コミットを特定description 内に「X tests」「既存A + 新規B」のような数値があれば、最新のテストファイルでカウントし直す。
# E2E
docker compose exec ms bash -c "cd admin && php -d memory_limit=-1 vendor/bin/phpunit --testsuite=e2e_tests <path>" | grep -E "OK \([0-9]+ tests|tests, "
# Unit
docker compose exec ms bash -c "cd admin && php -d memory_limit=-1 vendor/bin/phpunit <path>" | grep -E "OK \([0-9]+ tests|tests, "
description が methodName(?Type $arg = null) のような署名を含む場合、コードと一字一句照合する。
?int → ?Agent 等)description 内で個別のテストに言及している場合 (「ハッピーパス」「不正値で 400」等)、テストファイルから public function テスト名 を一覧化して照合する。削除されたテスト名が description に残っていれば検出する。
description で「XXX.php に追加」「XXX.php を変更」と書いているファイルが、実際の gh pr view --json files に含まれるか確認する。新規追加・削除されたファイルの言及漏れも検出する。
検出した不一致をユーザーに番号付きで提示する。各ドリフトは以下を含む:
例:
[D1] L47 メソッド名がリネームされている
description: `findOwnedAgentIdByAdvertiserId`
実際: `findOwnedAgentByAdvertiserId` (commit abc1234 でリネーム)
[D2] L57 テスト件数が古い
description: OK (19 tests)
実際: OK (18 tests) — `存在しないadvertiser_idの場合は400が返ること` が削除されている
[D3] L70 削除されたテストへの言及
description: 「認可: 存在しない ID、別総代理店配下の ID、論理削除済み ID のいずれも 400」
実際: 「存在しない ID」のテストは削除済み
ユーザーに「どの修正を適用するか」を確認する。基本は全件適用を推奨する。
判断不能なドリフトがあった場合 (例: description の意図と実装が食い違うがどちらが正か不明) はユーザーに方針を確認する。
/tmp/pr-sync-body.md を Edit ツールで修正する。各ドリフトに対して最小限の置き換えを行う。
修正後、PR に反映:
gh pr edit <num> --body-file /tmp/pr-sync-body.md
gh pr edit 後に念のため body を取り直し、コードブロック内のバッククォートがエスケープされていないかチェックする。
gh api repos/{owner}/{repo}/issues/comments/... --jq .body | grep '\\`' || echo "OK: no escaped backticks"
(コメントではなく PR の場合は gh api repos/{owner}/{repo}/pulls/<num> --jq .body で取得する)
description: ... (frontmatter) 内のキーワード「PR description を同期」「PR の本文を最新コードに合わせて」等は本 skill のトリガーになるので、似たフレーズで起動する