メニュー
コミットメッセージをConventional Commits規約に従って生成する。コミット作成、git commit、コミットメッセージの記述時に使用する。型の定義、フォーマット、本文の書き方ルールを含む。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | conventional-commits |
| description | コミットメッセージをConventional Commits規約に従って生成する。コミット作成、git commit、コミットメッセージの記述時に使用する。型の定義、フォーマット、本文の書き方ルールを含む。 |
コミットメッセージのフォーマット規約。全リポジトリ・全プロジェクト共通で適用する。
<型>: <タイトル>
[任意 本文]
| 型 | 説明 | Semantic Versioning |
|---|---|---|
feat | 新機能の追加 | MINOR |
fix | バグ修正、不具合の修正 | PATCH |
ui | UIや表示に関わる変更 | - |
refactor | リファクタリング（バグ修正でも機能追加でもないコード変更） | - |
style | コードの意味に影響を与えない変更（フォーマット、セミコロン等） | - |
test | テストの追加・修正 | - |
docs | ドキュメントのみの変更 | - |
revert | コミットの取り消し | - |
ci | CI/CD設定の変更 | - |
infra | インフラ関連の変更（IaC、設定ファイル等） | - |
chore | ライブラリの追加・削除など、コード本体に影響しない作業 | - |
local | ローカル環境のみに影響する変更 | - |
feat: を使用する (MUST)fix: を使用する (MUST)規則7（本文には変更の動機・背景を記述する）の具体化。形式は自由だが、以下の観点を含めることで後から文脈を復元できる。
ブランチ上のWIPコミットは未完成でもよい。ただし段階と意図がメッセージから読めること。
wip(parser): add token stream — tests red expectedgit trailers で構造化メタデータを付与してもよい（強制ではない）。
Stage: implementation
Context: planner output applied, integration pending
本文なし:
feat: allow provided config object to extend other configs
docs: correct spelling of CHANGELOG
本文あり（薄い — 意図が読めない）:
fix: fix the bug
Fixed the issue.
本文あり（十分 — 段階・意図・背景が読める）:
fix: prevent racing of requests
Stage: implementation — request dedup logic
API呼び出しが並行して走ると古いレスポンスが最新を上書きする問題。
リクエストIDを導入し、最新リクエスト以外のレスポンスを破棄する。
本文あり（WIP — 未完了だが文脈復元可能）:
wip(auth): add JWT validation middleware — happy path only
Stage: implementation — auth middleware scaffold
トークン検証のhappy pathのみ実装。次ステップ:
- 期限切れトークンのエラーハンドリング
- リフレッシュトークンフロー
親子 Claude Code セッション間の委譲操作を行う。delegate（子を起動してキック）、send（既存ペインへ1行/キックオフ送信・誤送信防止つき）、list（宛先確認）、report（子→親の申し送り）を自然言語の意図から判断して実行する。tmux 環境前提。
oe-* オーケストレーションツール群（engine 本体 / 親子委譲 / SO ゲート / 選択・観測）と駆動層規律の統合概観。複数エージェント委譲・設計SO/実装SO・read-only 観測・engine 1 サイクルを使うとき、ツール群の全体像をリポジトリ走査でなく一貫した形で把握したいときに使用する。
エラー/バグ調査で、入力→出力のコードパスに未読区間がある限り外部要因（インフラ差異等）の仮説に進まない。外部要因に飛ぼうとするとき、原因が再現しないと判断しそうなときに使用する。仮説を tmp/hypothesis-NNN.md に外部化し、コードパスの read-state を可視化する。
プランをKickoff Document形式に変換する。セカンドオピニオン投入・リポジトリアーカイブ・ピアレビュー共有時に使用する。命名規約・frontmatter・セクション構造をKickoff形式に整える。
設計判断を確定する前に、ゼロベースで未探索の代替案を最低1回引き出し、その証跡を確定前に残してから確定する。複数の選択肢を A/B 等で確定しかけたとき、ADR / Decision / kickoff の設計判断（DJ-N）を確定・記録するときに使用する。so-compare 選択肢拡張・探索木の外部化を含む。
so-compare.shでセカンドオピニオン（Codex/Claude/Cursor）を取得し、結果を比較する。ピアレビュー、修正方針の検証、設計判断の反証に使用する。**弱 SO**（1周可・partial=disclose・0はなし）。プロンプト設計原則、結果読み込み手順、合意判定基準を含む。