メニュー
既存PRのdescriptionをコードの現状に合わせて更新する。 「PR説明文を更新」「descriptionを更新」「update-pr-description」「PR本文を直して」 「PRの説明文がコードと合ってない」「descriptionを最新にして」「PRのdescription更新して」 「PRの内容を最新にして」などのリクエストで使用。 PRのURLや番号が提示された場合にも、description更新の文脈であればこのスキルを使うこと。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | update-pr-description |
| description | 既存PRのdescriptionをコードの現状に合わせて更新する。 「PR説明文を更新」「descriptionを更新」「update-pr-description」「PR本文を直して」 「PRの説明文がコードと合ってない」「descriptionを最新にして」「PRのdescription更新して」 「PRの内容を最新にして」などのリクエストで使用。 PRのURLや番号が提示された場合にも、description更新の文脈であればこのスキルを使うこと。 |
既存PRのdescriptionを、コードの実際の変更内容と比較し、不整合を検出して更新する。
PR番号またはURLを引数で受け取る。省略時はAskUserQuestionで確認。
URLまたはPR番号からowner/repo/numberを抽出する。カレントディレクトリがgitリポジトリ内の場合は --repo を省略可。
並列実行:
# PR基本情報（description含む）
gh pr view <number> [--repo <owner>/<repo>] --json title,body,headRefName,baseRefName,commits,files,additions,deletions,changedFiles
# PR diff（実際のコード変更）
gh pr diff <number> [--repo <owner>/<repo>]
プロジェクト固有のPRテンプレートを動的に検出し、descriptionの期待される構造を把握する。
検出順序（最初に見つかったものを使用）:
| 優先度 | パス |
|---|---|
| 1 | .github/PULL_REQUEST_TEMPLATE.md |
| 2 | .github/pull_request_template.md |
| 3 | docs/pull_request_template.md |
テンプレートが見つからない場合は、descriptionの見出し構造（## ...）からセクションを推定する。
PR作成ワークフローの検出（任意）:
見つかった場合は、各セクションの書き方の指針として参照する。
| パス |
|---|
.ai/workflows/create-pr-description.md |
.cursor/commands/create-pr-description.md |
既存のdescriptionを、テンプレート構造に基づいてセクション単位に分解する。テンプレートの ## 見出しを区切りとして使用する。
PR diffと変更ファイル情報を分析し、以下を把握する:
| 分析観点 | 具体的に見ること |
|---|---|
| 変更ファイル | 追加・変更・削除されたファイルの一覧 |
| 変更の種類 | 新規追加、修正、リファクタ、テスト追加、設定変更 |
| 主要な変更内容 | クラス・メソッド・APIの追加/変更/削除 |
| テスト | テストファイルの変更内容 |
| DB変更 | マイグレーションファイルの有無と内容 |
各セクションについて、実際のコード変更との整合性を判定する。
| セクション例 | チェック観点 |
|---|---|
| やったこと / Changes | diffに含まれる変更がすべて記載されているか。記載はあるが実際にはない変更はないか |
| やらなかったこと / Out of scope | 明らかにスコープ外にした事項の記載漏れはないか |
| 確認方法 / How to verify | 実装した機能に対応する確認手順が書かれているか |
| QA観点 / Testing scope | 影響範囲が実際の変更と一致しているか |
| 関連リンク / Links | 既存記載の維持（変更しない） |
| キャプチャ / Screenshots | 既存記載の維持（変更しない） |
判定結果の分類:
| 判定 | 意味 | 対応 |
|---|---|---|
| 整合 | 記載内容がコード変更と一致 | 変更なし |
| 不足 | コード変更に対応する記載が不足 | 追記を提案 |
| 不正確 | 記載内容がコード変更と矛盾 | 修正を提案 |
| 過剰 | コードに存在しない変更が記載されている | 削除を提案 |
| 未確認 | コードから判断困難（関連リンク、キャプチャ等） | スキップ |
変更がない場合: 「descriptionは現在のコード変更と整合しています。更新は不要です。」と報告して終了。
変更がある場合: 以下の形式で変更提案を表示する。
## PR Description 更新提案
**PR**: #<number> <title>
**ブランチ**: <head> → <base>
### 変更サマリー
| セクション | 判定 | 変更内容 |
|-----------|------|---------|
| やったこと | 不足 | 〜の記載を追加 |
| 確認方法 | 不正確 | 手順を実装に合わせて修正 |
| やらなかったこと | 整合 | 変更なし |
### 各セクションの変更詳細
#### 「やったこと」セクション（不足）
**理由**: diffに〜の変更が含まれるが、descriptionに記載がない
**現在の記載**:
> {現在のセクション内容}
**提案する記載**:
> {更新後のセクション内容}
出力ルール:
| ルール | 詳細 |
|---|---|
| 変更なしセクション | サマリー表に「整合 / 変更なし」として表示するが、詳細は省略 |
| 変更理由 | 各セクションの変更に必ず「理由」を明記する。ユーザーが「なぜ不整合と判断したか」を理解できるようにするため |
| 既存記載の尊重 | 正確な記載はそのまま残す。文体・トーンを維持する |
| テンプレート構造の維持 | セクションの追加・削除・順序変更はしない |
| HTMLコメント | テンプレートのHTMLコメント（<!-- ... -->）は元の状態を維持 |
| チェックボックス | QA result OKラベル等のチェック状態は変更しない |
| 確認方法の推測 | コード変更から手動確認手順を推測する。API変更ならエンドポイントのテスト手順、UI変更なら操作手順、内部リファクタなら既存機能の動作確認手順 |
提案した変更内容についてユーザーの確認を取る。
| ユーザーの応答 | 対応 |
|---|---|
| 承認（y, OK, いいよ 等） | Step 8へ進む |
| 修正依頼 | 指摘箇所を修正して再提示 |
| 一部採用 | 指定されたセクションのみ反映 |
| 却下 | 「更新をキャンセルしました」と報告して終了 |
ユーザーの明示的な承認なしに gh pr edit を実行しない。PRのdescription更新はチームメンバーに影響する変更であり、慎重に行う必要がある。
承認された更新内容を反映する。
gh pr edit <number> [--repo <owner>/<repo>] --body "$(cat <<'EOF'
{更新後のdescription全文}
EOF
)"
更新後、PRのURLとともに変更したセクションのサマリーを報告する。
| エラーパターン | 対処 |
|---|---|
| PR番号・URLが不正 | URLの形式を確認し、ユーザーに再入力を依頼 |
| アクセス権なし（HTTP 404） | gh auth statusで認証確認を案内 |
| diffが取得できない | gh apiでファイル単位のdiffを取得 |
| descriptionが空 | PRテンプレートをベースに新規作成を提案。ただしこのスキルの主目的は「更新」であり、初回作成はPR作成ワークフローの使用を案内 |
| テンプレートがない | description内の ## 見出しからセクションを推定して処理を続行 |
gh pr edit 失敗 | エラー内容を報告。権限問題の場合は手動更新を案内 |
| 操作 | 使用先 |
|---|---|
| 既存PR descriptionの更新 | このスキル |
| PR descriptionの新規作成 | PR作成ワークフロー（プロジェクト固有） |
| PRの全体レビュー | /reviewing-pr |
| PRレビューコメントへの対応 | /review-pr-comments |
| PR/Issue情報取得・作成 | /github |
| commit + push | /push |
Gmailの受信トレイ定期メンテナンスを一括実行する。迷惑メール削除＋購入・ソーシャル・プロモーションタブの未読メールをまとめてアーカイブ＆既読化。「受信トレイ整理」「メール整理」「inbox整理」「メールクリーンアップ」「迷惑メールとプロモを片付けて」「ソーシャルとプロモまとめてアーカイブ」「定期メールメンテ」「cleanup-inbox-mail」「Gmail掃除」などのリクエストで必ず使用する。「何通溜まってる？」「どれくらい溜まってる？」のような整理前の件数確認の質問でも必ず使用する（この場合は件数報告のみ行い、実行はしない）。Gmailの一括クリーンアップを希望する場合のデフォルトスキル。複数カテゴリの整理を一度のリクエストでまとめて指示された場合（例: 「迷惑メール削除して、購入とソーシャルとプロモもアーカイブ」）も、個別にgmailスキルを呼び出すのではなくこのスキルを使う。特定カテゴリのみの言及（例:「迷惑メールとプロモを片付けて」）は、言及されたカテゴリのみを対象にする。
既存スキルをSonnetなど小さいモデルで実行しても品質が下がらないように改善する。 静的分析→ba提案→承認後適用→Sonnet subagentでの改善前後A/B検証まで一気通貫で行う。 「Sonnet向けに改善」「Sonnet対応にして」「小さいモデルでも動くように」「Sonnet耐性」 「improve-skill-for-sonnet」「モデルを下げても品質が落ちないように」「Haiku/Sonnetで実行する予定のskillを改善」 などのリクエストで使用。skillの実行モデルを下位モデルに切り替える予定がある文脈でも必ず使用する。
Automate browser interactions, test web pages and work with Playwright tests.
research MDを元に詳細な実装計画（plan MD）をObsidian Vault（my-vault）に生成する。 「実装計画」「plan作成」「計画を書いて」「plan MD作成」「実装プラン」 「計画を立てて」「プランを作って」などのリクエストで使用。 機能実装・リファクタリング・バグ修正の計画を立てる場面で使用する。
コードベースを深く調査し、research MDをObsidian Vault（my-vault）に生成する。 「コードベースリサーチ」「codebase research」「深く調査して」「research MD作成」 「コードを調査してresearchにまとめて」「リサーチして」などのリクエストで使用。 既存コードの理解、実装前の調査、アーキテクチャの把握が必要な場面で使用する。
過去のレビュー指摘に基づくセルフチェックを行い、同じ誤りを未然に防ぐ。 「セルフレビュー」「セルフチェック」「self-review」「レビュー前にチェック」 「指摘されそうなところ確認」「フィードバックチェック」などのリクエストで使用。 実装完了後やPR作成前に、過去の指摘と同じパターンがないか確認したい場合に使用。