メニュー
PRを作成するスキル。変更内容を分析し、雲・雨・傘論法でPR概要を自動生成してghコマンドでPRを作成する。「PR作って」「プルリク作成」「create-pr」「/create-pr」などで起動する。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Google BigQuery を使ったデータ探索・クエリ実行スキル。プロジェクト healthy-person-emulator のデータセット（GA4, Search Console, dbt加工済みデータなど）に対して、スキーマ確認・データ探索・SQLクエリを実行する。 以下のようなフレーズでトリガーされる： - 「BigQueryで調べて」「BQでクエリして」「BigQueryのデータ見て」 - 「GA4のデータ集計して」「アクセス数を調べて」「PV数教えて」 - 「検索パフォーマンス見せて」「Search Consoleのデータ」「検索クエリ分析」 - 「データセット一覧」「テーブルのスキーマ確認」「カラム一覧」 - 「SQLで分析して」「集計して」「レポート出して」 ユーザーがサイトのアクセスデータ、検索パフォーマンス、ユーザー行動などを分析したいと言った場合は、 たとえ「BigQuery」という単語を使わなくてもこのスキルを使うこと。 GA4、Search Console、サイト分析に関するリクエストには積極的にこのスキルを適用する。
Cloudflare GraphQL Analytics API を使ったトラフィック分析スキル。ユーザーエージェント分析、ボット検出、リクエスト数の確認などを行う。 以下のようなフレーズでトリガーされる： - 「Cloudflareのログ確認して」「アクセスログ見て」「トラフィック分析して」 - 「ユーザーエージェント調べて」「どんなボットが来てる？」「クローラー確認」 - 「リクエスト数を調べて」「アクセス状況確認して」 サイトへのアクセス状況、ボット、ユーザーエージェントについて聞かれた場合はこのスキルを使う。
Codexを使って厳しい上司として Claude のプラン・提案・意見をレビューさせる。「Codexにレビューさせて」「上司にチェックしてもらう」「ボスにレビューしてもらう」「/codex-review」「codex-review」「Planをボスに確認させて」「厳しい目でチェックして」などのフレーズで起動する。また、重要なプランを確定する前（plan モードで最終提案をまとめる直前）にも自律的に使用すること。
agent-browser（ヘッドレスブラウザCLI）を使って、ブラウザ上の変更が正しく反映されたかを検証するE2Eテストスキル。UI変更、導線変更、フォーム操作、表示崩れ、回帰確認、console/networkエラー確認、レスポンシブ確認などを依頼されたときに使う。「テスターとして見て」「ブラウザで変更確認して」「E2Eテストして」「表示が直ったかテストして」などの依頼で起動する。
| name | create-pr |
| description | PRを作成するスキル。変更内容を分析し、雲・雨・傘論法でPR概要を自動生成してghコマンドでPRを作成する。「PR作って」「プルリク作成」「create-pr」「/create-pr」などで起動する。 |
| user_invocable | true |
変更内容を分析し、プロジェクトのPRテンプレートに沿ったPRを作成する。
以下を並列で実行し、PR本文の材料にする：
git diff origin/main...HEAD
git log origin/main..HEAD --oneline
Note: コミット一覧の検証（余計なコミットの混入チェック）は
check-pr-commits.shフックがgh pr create実行前に自動で行う。未コミットの変更やpush状態のチェックもフックに任せてよい。
.github/pull_request_template.md を読み込み、テンプレートに沿ってPR本文を作成する。
変更の全コミットを分析して3行で書く：
例：
- CIがテスト実行のみで、ビルド検証やインフラ差分確認ができていない
- コードが壊れたまま本番デプロイされるリスクがある
- 変更パターンに応じてtest/build/terraform plan/container checkを実行するCIパイプラインを構築した
コミット単位ではなく、論理的なまとまりごとに見出し（##）で区切って書く。
書き方のルール：
## 見出し + 1行の要約 + 箇条書き or 表の構成にする悪い例（読みづらい）：
- **CI ワークフロー** (`ci.yml`): `.md`等を除く全変更で `pnpm test` + `pnpm typecheck` + `pnpm build` を実行。旧`vitest.yml`を置換
良い例（読みやすい）：
## GitHub Actions ワークフロー（4ファイル新規作成、1ファイル削除）
`vitest.yml`（テストのみ）を廃止し、以下4つのワークフローに置き換えた。
| ワークフロー | いつ動くか | 何をするか |
|---|---|---|
| `ci.yml` | `.md`等を除く全変更 | test → typecheck → build |
チェックボックス形式で書く。実際に確認した内容のみ記載する。
- [x] 全パターン変更（本PR）: CI / Container Check / Merge Gate が全て success
- [x] `.md` のみ変更: Merge Gate のみ即success（他ワークフローは未発動）
- [x] ローカルで `pnpm typecheck` が通ること
実装時に参照した公式ドキュメント、Issue、PRなどのURLを記載する。実際に参照したものだけを書き、関連しそうというだけで載せない。なければセクションごと省略。
レビュアーに伝えておくべき注意点、今後の課題、意図的にスコープ外にしたことなどを書く。なければセクションごと省略。
gh pr create --title "タイトル" --body "$(cat <<'EOF'
本文
EOF
)"
🤖 Generated with [Claude Code](https://claude.com/claude-code) を付与PR URLをユーザーに返す。
このスキルを使ってPRを作成した結果、改善した方が良いと考える点がある場合は、ユーザーに相談した上でこのスキルファイル自体を更新すること。