このドキュメントは、codex/skills で管理している skill の用途を素早く把握するための一覧です。
各 skill の実体は codex/skills/internal/<skill-name>/SKILL.md にあります。外部 skill は external-skills.json の設定に従って deploy 時に取得されます。
分類は docs/guide/skill-category.md の考え方に合わせています。複数の性質を持つ skill は、主な用途で分類しています。
skill 間の明示的な併用・優先関係は docs/skill-dependency-map.md にまとめています。
「何をするか」を定義する skill です。ワークフロー型、ロール型、出力フォーマット型を中心に分類しています。
| Skill | 概要 | 使う場面 |
|---|---|---|
agent-retro |
直近のエージェント作業を振り返り、再利用可能なルールへ反映する。 | 遠回りした知見を skill、AGENTS.md、CLAUDE.md などに残したいとき。 |
cmd-batch |
広範囲の調査、編集、検証を複数エージェントや並列作業へ分割する。 | 大規模変更、横断調査、複数担当への分担、統合手順の整理が必要なとき。 |
cmd-commit |
変更内容を確認し、適切な粒度とメッセージで安全に Git commit を作成する。 | commit 作成を依頼されたとき。未確認の変更や unrelated changes を含めず、stage 対象と message を整理する。 |
cmd-create-pr |
GitHub Pull Request を安全な手順で作成または更新する。 | PR 作成、PR 提出、pull request 作成を依頼されたとき。差分確認、検証、commit、role-reviewer による PR 前レビュー、High 指摘の自動対応、grape push、PR description 作成、gh pr create / edit の順序を整理する。 |
cmd-dispatch-agent |
指定された agent を起動し、結果を待たずにタスクを投げる。 | ユーザーが agent 起動、worker への委譲、投げっぱなし実行を明示したとき。明示がなくても、単純で不明瞭な点がない自己完結タスクを任せたいとき。 |
cmd-rmbranch |
main と develop を残し、不要なローカルブランチを安全に削除する。 |
ローカルブランチ整理を依頼されたとき。未マージブランチは確認してから扱う。 |
cmd-start-branch |
最新のデフォルトブランチから許可された prefix の作業ブランチを作り、不要ブランチ整理を非同期に依頼する。 | 新しい作業を始める前に「ブランチ切って」「作業開始用ブランチを作って」などを依頼されたとき。ブランチ名を報告してタスク詳細を待つ。 |
beautify-commit |
ベースブランチまたは基準 commit との差分を、意味のある変更単位の commit へ安全に整理する。 | commit 分割、履歴整理、大きすぎる差分の再 commit、ベースブランチや commit hash を基準にした差分整理を依頼されたとき。interactive rebase が必要な整理は grape の対応まで実行しない。 |
ci-fix |
GitHub Actions / CI の失敗を調査し、原因切り分けから修正、再検証まで進める。 | CI、GitHub Actions、checks、workflow、test / lint / build failure の修正を依頼されたとき。 |
code-refactor |
挙動を変えずにコードを簡略化、リファクタリングする。 | レビュー指摘、quality report、diff、指定ファイルをもとに可読性、保守性、テスト容易性を改善するとき。 |
code-test |
テスト設計、回帰テスト追加、テストコードレビュー、テスト戦略を整理する。 | 正常系、異常系、境界値、flake、モック方針を検討するとき。 |
code-tracer |
特定シンボルや関数の callers / callees / both を根拠付きで追跡する。 | 呼び出し経路、影響範囲、依存関係を Markdown や Mermaid で可視化したいとき。 |
code-general |
言語固有スキルが適用できない、または言語をまたぐ実装作業の共通原則。 | 既存構造、命名、責務境界に合わせて小さく安全な差分を作るとき。言語固有の判断では該当する言語別スキルを併用する。 |
component-design |
React / Next.js / TypeScript UI の実装前に、画面構成とコンポーネント境界を設計する。 | 新規画面、大きな JSX 分割、既存 UI へのまとまった機能追加を行う前。 |
documenting |
README、ADR、Runbook、API Docs、開発者向け文書を作成、更新する。 | 変更理由、影響範囲、互換性、運用注意、戻し方を未来の開発者へ残すとき。 |
lego-programming |
実装対象や差分を高凝集・疎結合な部品として境界づけ、組み合わせ、見直す。 | 実装、リファクタリング、コードレビュー、UI 分割、モジュール設計で責務分離や再利用単位を確認したいとき。 |
modification-design |
実装前に変更後の責務、公開 interface、contract、依存構造、影響、リスクを自然言語で設計する。 | Plan や実装手順ではなく、変更後のシステム構造をレビュー可能な形で固めたいとき。 |
| Skill | 概要 | 使う場面 |
|---|---|---|
issue-finder-playbook |
Issue Finder agent の調査、安全制約、品質基準、Markdown 出力 contract を定義する。 | 各 finder playbook と組み合わせて、コードを変更せず課題を発見・出力するとき。 |
role-bug-finder |
issue-finder agent へ不具合発見を委譲する。 |
コードベースの再現可能な不具合、仕様違反、境界条件の欠陥を探すとき。 |
role-bug-finder-playbook |
不具合発見の探索観点と判定基準を定義する。 | Issue Finder agent が不具合を調査するとき。 |
role-maintenance-finder |
issue-finder agent へ保守性課題の発見を委譲する。 |
責務混在、複雑性、重複、変更・テスト困難性を探すとき。 |
role-maintenance-finder-playbook |
保守性課題の探索観点と判定基準を定義する。 | Issue Finder agent が保守性を調査するとき。 |
role-feature-finder |
issue-finder agent へ機能提案の発見を委譲する。 |
リポジトリ内の根拠から利用者の未解決課題と機能案を探すとき。 |
role-feature-finder-playbook |
根拠のある機能提案の探索観点と判定基準を定義する。 | Issue Finder agent が機能提案を調査するとき。 |
role-vulnerability-finder |
issue-finder agent へ脆弱性発見を委譲する。 |
コード、設定、依存関係、権限境界の悪用可能な問題を安全に探すとき。 |
role-vulnerability-finder-playbook |
脆弱性発見の安全境界、探索観点、判定基準を定義する。 | Issue Finder agent が脆弱性を調査するとき。 |
role-documentation-finder |
issue-finder agent へ文書課題の発見を委譲する。 |
文書の不整合、配置、導線、progressive disclosure の問題を探すとき。 |
role-documentation-finder-playbook |
文書課題の探索観点と判定基準を定義する。 | Issue Finder agent が文書構造と整合性を調査するとき。 |
role-advisor |
advisor agent へ技術助言を委譲する。 |
技術判断や設計相談が必要なとき。 |
role-advisor-playbook |
Advisor agent の助言方針を定義する。 | advisor agent が技術助言を行うとき。 |
role-documenter |
documenter agent へ技術文書の作成・更新を委譲する。 |
調査から構成、作成、文書全体のレビューまで一貫した文書化が必要なとき。 |
role-documenter-playbook |
Documenter agent の文書化手順と判断基準を定義する。 | documenter agent が技術文書を作成・更新するとき。 |
role-gardener |
gardener agent へ Git / GitHub 操作を委譲する。 |
内容の解釈を伴わない repository、branch、worktree、PR、Issue の操作が必要なとき。 |
role-gardener-playbook |
Gardener agent の Git / GitHub 操作方針と責務境界を定義する。 | gardener agent が Git / GitHub の機械操作を行うとき。 |
role-implementer |
implementer agent へ実装を委譲する。 |
計画に沿ったコード実装が必要なとき。 |
role-implementer-playbook |
Implementer agent の実装方針を定義する。 | implementer agent が実装を行うとき。 |
role-planner |
planner agent へ計画作成を委譲する。 |
実装前の計画整理が必要なとき。 |
role-planner-playbook |
Planner agent の計画方針を定義する。 | planner agent が計画を作成するとき。 |
role-refactor |
refactor agent へ構造改善の設計を委譲する。 |
挙動を維持したリファクタリングが必要なとき。 |
role-refactor-playbook |
Modification Design、Implementer、Reviewer の反復手順を定義する。 | refactor agent が構造改善を設計・統括するとき。 |
role-reviewer |
reviewer agent へレビューを委譲する。 |
実装済み変更のレビューが必要なとき。 |
role-reviewer-playbook |
Reviewer agent のレビュー方針を定義する。 | reviewer agent がレビューを行うとき。 |
role-scouter |
scouter agent へ調査を委譲する。 |
コードや設定の調査が必要なとき。 |
role-scouter-playbook |
Scouter agent の調査方針を定義する。 | scouter agent が調査を行うとき。 |
role-worker |
worker agent へ機械的な作業を委譲する。 |
コマンド実行、定型操作、検証が必要なとき。 |
role-worker-playbook |
Worker agent の機械的な作業方針を定義する。 | worker agent がコマンド作業や検証を行うとき。 |
| Skill | 概要 | 使う場面 |
|---|---|---|
format-pr-description |
GitHub Pull Request の description を定義済みフォーマットで作成、更新する。 | PR 番号、diff、コミット履歴から Summary、変更点、動作確認を整理するとき。 |
format-rich-html-diagram |
アーキテクチャ、コンポーネント構造、データフロー、状態管理、シーケンス、処理フローを単一 index.html でリッチに可視化する。 |
開発理解、設計整理、コードリーディング、オンボーディング用に、ブラウザで開ける図解資料を作りたいとき。 |
「どう考え、どう評価するか」を定義する skill です。判断基準・評価型、思想・スタイル型、スコアリング・査定型を中心に分類しています。
| Skill | 概要 | 使う場面 |
|---|---|---|
code-naming |
関数名、クラス名、型名、変数名などコード要素の命名候補や改善案を出す。 | 責務、抽象度、既存語彙、検索性、ユーザーの命名の好みに沿って名前を比較・改善したいとき。 |
code-next-developer-review |
次に開発する人が困らないかという観点で差分をレビューする。 | 実装者の前提を鵜呑みにせず、敵対的検証を行い、命名、責務境界、型、テストの読みやすさ、前提知識の残し方を確認するとき。 |
code-review |
実装済み差分、PR、コミット、指定ファイルをリスク中心にレビューする。 | 実装者の前提を鵜呑みにせず、敵対的検証を行い、仕様違反、回帰、公開契約破壊、セキュリティ、データ整合性を確認するとき。 |
code-naming は判断基準・評価型にも近いですが、ユーザーの命名の好みを反映する思想・スタイル型の性質を持ちます。主分類は判断基準・評価型に置いています。
| Skill | 概要 | 使う場面 |
|---|---|---|
code-quality-review |
code quality report として、定量シグナル、品質スコア、scorecard、quality gate を整理する。 | 実装者の前提を鵜呑みにせず、敵対的検証を行い、complexity、coverage、重複率、lint などを補助証拠にしつつ、merge 前対応と follow-up の判断材料にしたいとき。 |
「何を避けるべきか」を定義する skill です。主にガードレール・制約型を分類します。
現時点で、この類型を主用途にする internal skill はありません。
「何を知っておくべきか」を提供する skill です。主に知識圧縮型を分類します。
| Skill | 概要 | 使う場面 |
|---|---|---|
code-css |
CSS / .css / Sass / SCSS / .scss 実装向けの layout、responsive design、selector、cascade、保守しやすいスタイル設計の参照。 |
CSS 実装を書く前に、スタイル設計の判断基準を確認するとき。 |
code-go |
Go / .go 実装と Go テスト向けの goroutine、interface、error handling、設計、テスト方針の参照。 |
Go 実装や Go テストを書く前に、実装ガイドを確認するとき。 |
code-react |
React / JSX / TSX / .jsx / .tsx 実装向けの hooks、props、state、Atomic Design を補助観点にしたコンポーネント設計の参照。 |
React 実装を書く前に、UI 実装ガイドを確認するとき。 |
code-ruby |
Ruby / Rails / .rb 実装と RSpec / Minitest テスト向けの Active Record、MVC、設計、テスト方針の参照。 |
Ruby / Rails 実装やテストを書く前に、実装ガイドを確認するとき。 |
code-ts |
TypeScript / .ts / .tsx 実装向けの型設計、interface / type、strict typing、責務分離の参照。 |
TypeScript 実装を書く前に、実装ガイドを確認するとき。 |
codex/skills/internal/deprecated/ 配下の skill は履歴保持用です。make deploy / make apply では配布されません。
| Skill | 理由 |
|---|---|
cmd-agent-status |
active skill としては配布せず、履歴保持のため deprecated へ移動した。 |
code-typo |
active skill としては配布しない。 |
role-doc |
active skill としては配布しない。 |
外部 skill は external-skills.json で取得元と配布先を管理します。
| Skill | 取得元 | 主な分類 | 概要 |
|---|---|---|---|
skill-creator |
anthropics/skills |
行動定義型 / ワークフロー型 | 新しい skill の作成、既存 skill の更新、メタデータや検証手順の整備に使う。 |
frontend-design |
anthropics/skills |
行動定義型 / ワークフロー型 | Web UI、ページ、コンポーネント、HTML/CSS/React などを高品質な frontend design として実装するときに使う。 |
grilling |
mattpocock/skills |
判断定義型 / 判断基準・評価型 | 計画や設計を厳しく質問し、曖昧さや判断漏れを潰すために使う。 |
empirical-prompt-tuning |
mizchi/skills |
判断定義型 / スコアリング・査定型 | skill やプロンプトを実験的に改善し、評価と反復で性能を詰めるために使う。 |
grape-usage |
version-1/grape |
行動定義型 / リファレンス型 | 安全な push、ポリシーで制限された rebase、worktree 操作など、grape コマンドの正確な利用方法を確認するときに使う。 |
- 新しい internal skill を追加したら、この一覧にも追記する。
- 追加時は docs/guide/skill-category.md を参照し、主用途に最も近い分類へ配置する。
- 複数カテゴリにまたがる skill は、重複掲載せず主分類に置き、必要に応じて概要に複合要素を明記する。
code-generalやcode-reviewのようにガードレールや思想を含む skill でも、一覧では主な行動や判断の用途を優先して配置する。codex/skills/internal/<name>/agents/openai.yamlがある場合は、UI 表示用の説明もSKILL.mdと矛盾しないように更新する。- 他 skill への明示的な依存や利用順序を追加したら、docs/skill-dependency-map.md も更新する。
- deploy 前は
make deploy-dry-runで配布対象に含まれることを確認する。