メニュー
壁打ち用スキル。指示された内容の実現方法を、リポジトリのソースコードの観察・外部の最新OSS実装や実践事例の調査を踏まえて検討し、実装案や実現可能性を提示する。ユーザーが「これってできる？」「どうやって実装する？」「こういう機能を入れたい」「設計を相談したい」「壁打ちしたい」といった探索的・検討段階の相談をしたときに使うこと。spec作成（/dev）の前段階での利用を想定している。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
OpenAI Codex を MCP 経由（mcp__codex__codex）で呼び出し、セカンドオピニオンとしてコードレビュー・調査をさせるスキル。引数がなければ現在のリポジトリの変更（staged/unstaged含む）またはdefault branchとの差分をレビューさせ、引数（テーマ・ファイル・バグの症状など）があればそれについて調査・レビューさせる。観点は保守性・テスト十分性・spec適合・実装の筋の良さなど。ユーザーが「codexでレビューして」「codexに見てもらって」「codexで調べて」「別のモデルの意見も欲しい」「セカンドオピニオン」と言ったとき、あるいは自分のレビューを別視点で裏取りしたいときに使う。トリガー: codex-review, codexレビュー, codexで見て, /codex-review
spec-driven developmentを開始・継続する。新しい開発タスク、specの作成、実装の開始・再開など、開発に関わるあらゆるフェーズで使用せよ。ユーザーが開発タスクについて言及したとき、feature branchでの作業を始めるとき、実装を進めたいときに必ずこのスキルを使うこと。
Claudeセッションのログ（ディレクトリ指定があればそのリポジトリの過去全 worktree、指定がなければ現在実行中のセッション）を分析し、設計・実装中にユーザーから受けた指摘・軌道修正・ダメ出しや、Claude自身のつまずきを「教訓」として蒸留し、行き先を見極めてコーディングルールへ反映するスキル。一般化できる改善点・設計思想・実装技法はグローバルルール（~/.claude の CLAUDE.md / rules）へ、そのプロジェクト固有の事情で寄り道・難航した知見はそのリポジトリの .claude（CLAUDE.md / rules）へと、肥大させずに振り分ける。「この指摘を二度とさせたくない」「さっきの反省をルールに落としたい」「セッションを振り返ってルールにして」「最近の指摘から学習して」「同じミスを繰り返さないようにルール化して」「reflection」「振り返って」と言われたとき、また長いセッションでユーザーが何度も似た修正を入れていたと気づいたときにも積極的に使うこと。コードベースからルールを起こす refine-rules とは入力が違い、こちらは「人間がClaudeに与えたフィードバック」を入力にする。
現在のリポジトリの変更（staged/unstaged含む）またはdefault branch (main/master) との差分とその周辺コードを読み、実装の良し悪しを評価するコードレビュースキル。保守性・テスト十分性・spec適合・実装の筋の良さなどの観点から、プロの視点で良い点と問題点を指摘する。ユーザーが「レビューして」「コードレビューして」「この実装どう？」「変更を見て」「品質チェックして」「マージ前に確認して」と言ったとき、あるいは実装が一段落して評価が欲しそうなときに必ず使うこと。バグ修正だけが目的の場合は別だが、設計・実装の質を評価する文脈では積極的に発動する。
現在のブランチのPRのレビューコメントとCIステータスを確認し、問題があれば修正する
リポジトリのコードベースを分析してClaude Code用のコーディングルール（CLAUDE.md / .claude/rules/）を生成・更新し、併せてコードベース側の不足や問題点も指摘・修正する。「ルールを作りたい」「コーディング規約を整えたい」「CLAUDE.mdを作りたい・見直したい」「.claude/rulesを整備したい」「このリポジトリのルールを書いて」「プロジェクトのコーディングスタイルを整えて」といったリクエストで使うこと。新規リポジトリの初期設定にも、既存ルール・既存コードベースの継続的な見直し・改善にも対応する。
| name | brainstorm |
| description | 壁打ち用スキル。指示された内容の実現方法を、リポジトリのソースコードの観察・外部の最新OSS実装や実践事例の調査を踏まえて検討し、実装案や実現可能性を提示する。ユーザーが「これってできる？」「どうやって実装する？」「こういう機能を入れたい」「設計を相談したい」「壁打ちしたい」といった探索的・検討段階の相談をしたときに使うこと。spec作成（/dev）の前段階での利用を想定している。 |
| allowed-tools | Read, Write, Edit, Bash, Grep, Glob, Agent, WebFetch, WebSearch, AskUserQuestion |
ユーザーのアイデアや課題について、コードベースの実態と外部知見を組み合わせて実装案を検討するスキル。spec-driven development（/dev）の前段階、つまり「何をどう作るか」を固める探索フェーズで使う。
ユーザーの発言から以下を読み取る：
曖昧な場合は、AskUserQuestionで最小限の確認をする。ただし質問攻めにはしない。まず手を動かして調べ、調査結果をもとに具体的な選択肢を提示するほうが建設的。
相談内容に関連するコードを徹底的に調べる。Agent（Explore）を活用して並列に調査すると効率的。
調べるべきこと：
単にファイルを列挙するのではなく、「この設計判断にはこういう意図がある」「ここがボトルネックになりそう」といった洞察を得ることが目的。
必要に応じてWebSearch/WebFetchで外部情報を収集する。以下のような場合に特に有用：
調査は目的を持って行う。「とりあえず検索する」のではなく、コードベース観察で得た仮説を検証する、あるいは不足している知識を補うために使う。
調査時の注意:
調査結果を統合して実装案を組み立てる。
各案には以下を含める（必要に応じて取捨選択）：
形式は内容に合わせて柔軟に。ただし以下の構造を基本とする：
## 検討結果
### 前提の整理
[コードベース観察と外部調査から得た、案の前提となる事実]
### 案1: [案の名前]
[概要、アプローチ、根拠、トレードオフなど]
### 案2: [案の名前]（複数案がある場合）
[同上]
### 比較（複数案がある場合）
| 観点 | 案1 | 案2 |
|------|-----|-----|
| ... | ... | ... |
### 推奨
[どの案を推すか、あるいはユーザーの判断が必要な点]
案を提示した後、あるいは案を組み立てる過程で、不明点や曖昧な点が見えてくる。これらを放置せず、AskUserQuestionを使って構造的に深掘りする。
質問は1回あたり2〜4個程度に絞る。「調べれば分かること」は質問せず自分で調べる。ユーザーに聞くのは、ユーザーしか持っていない情報（ビジネス要件、優先度、運用上の制約など）に限る。
深掘りの結果、方針が明確になったら：
/dev でspec作成に進められるよ」と伝える/dev の役割）