القائمة
過去のレビュー指摘に基づくセルフチェックを行い、同じ誤りを未然に防ぐ。 「セルフレビュー」「セルフチェック」「self-review」「レビュー前にチェック」 「指摘されそうなところ確認」「フィードバックチェック」などのリクエストで使用。 実装完了後やPR作成前に、過去の指摘と同じパターンがないか確認したい場合に使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Gmailの受信トレイ定期メンテナンスを一括実行する。迷惑メール削除＋購入・ソーシャル・プロモーションタブの未読メールをまとめてアーカイブ＆既読化。「受信トレイ整理」「メール整理」「inbox整理」「メールクリーンアップ」「迷惑メールとプロモを片付けて」「ソーシャルとプロモまとめてアーカイブ」「定期メールメンテ」「cleanup-inbox-mail」「Gmail掃除」などのリクエストで必ず使用する。「何通溜まってる？」「どれくらい溜まってる？」のような整理前の件数確認の質問でも必ず使用する（この場合は件数報告のみ行い、実行はしない）。Gmailの一括クリーンアップを希望する場合のデフォルトスキル。複数カテゴリの整理を一度のリクエストでまとめて指示された場合（例: 「迷惑メール削除して、購入とソーシャルとプロモもアーカイブ」）も、個別にgmailスキルを呼び出すのではなくこのスキルを使う。特定カテゴリのみの言及（例:「迷惑メールとプロモを片付けて」）は、言及されたカテゴリのみを対象にする。
既存PRのdescriptionをコードの現状に合わせて更新する。 「PR説明文を更新」「descriptionを更新」「update-pr-description」「PR本文を直して」 「PRの説明文がコードと合ってない」「descriptionを最新にして」「PRのdescription更新して」 「PRの内容を最新にして」などのリクエストで使用。 PRのURLや番号が提示された場合にも、description更新の文脈であればこのスキルを使うこと。
既存スキルを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にまとめて」「リサーチして」などのリクエストで使用。 既存コードの理解、実装前の調査、アーキテクチャの把握が必要な場面で使用する。
| name | checking-review-feedback |
| description | 過去のレビュー指摘に基づくセルフチェックを行い、同じ誤りを未然に防ぐ。 「セルフレビュー」「セルフチェック」「self-review」「レビュー前にチェック」 「指摘されそうなところ確認」「フィードバックチェック」などのリクエストで使用。 実装完了後やPR作成前に、過去の指摘と同じパターンがないか確認したい場合に使用。 |
過去のPRレビュー指摘（フィードバックDB）に基づいて、現在の変更にセルフチェックを行う。
参照先: /Users/shifumi.fukunaga/ghq/github.com/shifumin/my-vault/060_work/feedback-database.md
# stagingからの差分を取得
git diff staging...HEAD
# 変更ファイル一覧
git diff staging...HEAD --name-only
差分が大きい場合は変更ファイル一覧を先に確認し、主要な変更ファイルに絞って分析する。
フィードバックDBファイルをReadで読み込む。
ファイルが存在しない場合は「フィードバックDBがまだ作成されていません。accumulating-review-feedback スキルで指摘を蓄積してください。」と報告して終了する。
変更差分の内容と、フィードバックDBの各指摘の「チェックポイント」「状況」を照合する。
判定の観点:
判定は厳密なパターンマッチではなく、指摘の意図を理解した上での意味的な照合を行う。 誤検知（false positive）を減らすため、確信度が低い場合は「参考情報」として報告する。
## セルフレビュー結果
### 該当する過去の指摘
| ID | カテゴリ | 内容 | 対象ファイル | 該当理由 |
|----|---------|------|-------------|---------|
| {ID} | {カテゴリ} | {タイトル} | `{ファイルパス}:{行番号}` | {なぜ該当するか} |
### 各指摘の詳細
#### {ID}: {タイトル}
- **過去の教訓**: {教訓の内容}
- **今回の該当箇所**: {具体的なコード箇所の説明}
- **推奨対応**: {どう修正すべきか}
確信度が低いが注意した方がよい項目は「参考情報」として別セクションで報告する。
### 参考情報（確信度: 低）
以下は直接該当するとは断言できませんが、関連する過去の指摘です:
| ID | カテゴリ | 内容 | 関連理由 |
|----|---------|------|---------|
## セルフレビュー結果
過去の指摘に該当するパターンは検出されませんでした。
チェックした指摘数: {N}件
| エラー | 対処 |
|---|---|
| フィードバックDBが存在しない | accumulating-review-feedback スキルでの蓄積を案内 |
| stagingブランチが存在しない | ベースブランチをユーザーに確認 |
| 差分が空 | コミットされていない変更がないか確認し、報告 |