メニュー
リポジトリのコードベースを分析してClaude Code用のコーディングルール（CLAUDE.md / .claude/rules/）を生成・更新し、併せてコードベース側の不足や問題点も指摘・修正する。「ルールを作りたい」「コーディング規約を整えたい」「CLAUDE.mdを作りたい・見直したい」「.claude/rulesを整備したい」「このリポジトリのルールを書いて」「プロジェクトのコーディングスタイルを整えて」といったリクエストで使うこと。新規リポジトリの初期設定にも、既存ルール・既存コードベースの継続的な見直し・改善にも対応する。
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ステータスを確認し、問題があれば修正する
difitコマンドでGitのdiffをブラウザのGitHub風UIで表示する。コードレビューや差分確認時に使用。
| name | refine-rules |
| description | リポジトリのコードベースを分析してClaude Code用のコーディングルール（CLAUDE.md / .claude/rules/）を生成・更新し、併せてコードベース側の不足や問題点も指摘・修正する。「ルールを作りたい」「コーディング規約を整えたい」「CLAUDE.mdを作りたい・見直したい」「.claude/rulesを整備したい」「このリポジトリのルールを書いて」「プロジェクトのコーディングスタイルを整えて」といったリクエストで使うこと。新規リポジトリの初期設定にも、既存ルール・既存コードベースの継続的な見直し・改善にも対応する。 |
リポジトリのコードベースを観察し、Claude Codeが従うべきコーディングルールを生成・更新するスキル。併せて、コードベース側の不足や問題点（壊れたビルド、緩すぎるリンター、ルールと実装の乖離など）も指摘し、合意のうえで修正する。
Claude Codeには2つのルール配置先がある。用途に応じて使い分ける。
プロジェクトルートに置く単一ファイル。セッション開始時に必ず読み込まれる。
置くべきもの：
置くべきでないもの：
.claude/rules/ へ）配置場所のバリエーション：
./CLAUDE.md — プロジェクト共有（gitにコミット）./CLAUDE.local.md — 個人用（.gitignoreに入れる）~/.claude/CLAUDE.md — グローバル（全プロジェクト共通）ドメインごとにルールを分割するためのディレクトリ。中の .md ファイルはすべてセッション開始時に読み込まれる。
使い分けの目安：
testing.md, api-conventions.md, frontend.md のように内容を表す名前にする書き方： フロントマターやメタデータは不要。プレーンなMarkdownで書く。
参考ドキュメント：
以下を調査してリポジトリの特徴を把握する：
go.mod, package.json, Cargo.toml, pyproject.toml 等の依存定義ファイルMakefile, justfile, package.json の scripts, CI設定（.github/workflows/）.golangci.yml, .eslintrc, ruff.toml 等）、フォーマッター設定CLAUDE.md, .claude/rules/, .editorconfig 等コードベースを観察する過程で、以下のような「ルール以前の問題」に気づいたら、ルールを書く前にユーザーに指摘し、合意のうえで修正すること。ルールを整備しても土台が崩れていると意味がないため。
指摘・修正の対象：
.gitignore の漏れ（ビルド成果物・秘密情報の混入リスク）.claude/rules/ がコードベースの現状と乖離している進め方：
「ルールを書く」ことと「リポジトリを健全な状態にする」ことはセットで進める。
観察結果をもとに、何をCLAUDE.mdに書き、何を .claude/rules/ に分割するか決める。
CLAUDE.md に書く内容（目安）：
.claude/rules/ に分けるケース：
小〜中規模リポジトリなら CLAUDE.md だけで十分なことも多い。無理に分割しない。
ルールを書くときの原則：
fmt.Errorf("failed to %s: %w", action, err) の形式でラップする」のようにgo test ./... のようにそのまま実行できる形で生成したルールの内容をユーザーに見せ、過不足がないか確認する。ユーザーの修正指示を反映してからファイルに書き込む。
確認が取れたら CLAUDE.md や .claude/rules/ にファイルを作成・更新する。既存ファイルがある場合は内容をマージする（上書きしない）。
# プロジェクト名
簡潔な説明文。
## Development
- Build: `make build`
- Test: `make test`
- Lint: `make lint`
- Single test: `go test -run TestName ./path/to/package`
## Coding Rules
- エラーは必ず `%w` でラップして返す
- publicなAPIには godoc コメントを書く
- テストは table-driven test で書く
- 外部APIの呼び出しは interface 経由にする（テスタビリティのため）
<!-- .claude/rules/testing.md -->
# Testing
- テストライブラリは標準の `testing` パッケージ + `testify/assert` を使う
- テストヘルパーは `t.Helper()` を呼ぶ
- 外部サービスとの結合テストは `//go:build integration` タグで分離する
- テストデータは `testdata/` ディレクトリに置く
既に CLAUDE.md や .claude/rules/ が存在する場合：