odoo-commit-message-guidelines

Odoo のコミットメッセージガイドライン

目的

このスキルを使用して、一貫性があり、レビューしやすく、簡単に取り消せる、高品質な Odoo のコミットメッセージを作成します。

ローカルの参考資料

• references/git_guidelines.md — ヘッダーの判断基準と、WHAT より WHY を重視する考え方
• references/CONTRIBUTING.md — OCA の [MIG] タグ拡張とヘッダーの切り詰めチェック

これらは、例外的なケースの判断やポリシーの根拠を確認する場合にのみ参照してください。

使用するタイミング

ユーザーから次の依頼があった場合に、このスキルを使用してください。

• Odoo コードの新しいコミットメッセージを作成する
• 既存のコミットメッセージを書き直す、または改善する
• コミットメッセージが Odoo のルールに従っているか検証する
• 適切な Odoo タグを選択する

必須入力情報

下書きを作成する前に、モジュール名（または various）、変更の意図、WHY の根拠、および参照情報（task-*、ticket-*、Fixes #、Closes #、opw-*）や CI 指示（[NO CI]）を確認してください。

入力情報が不足している場合は、必要最小限の簡潔な追加質問のみをしてください。

出力形式

次の構成を使用してください。

[TAG] module: short summary (ideally < 50 chars)

WHY the change is needed.
WHAT changed and technical choices (only if useful).

task-123
ticket-12345
Fixes #123
Closes #456
opw-789

ルール：

• 英語のみを使用します。
• ヘッダーは [TAG] module: imperative summary の形式にします（約 50 文字）。
• タグは大文字で角括弧に囲み、「タグ選択ルール」に記載されたものを使用します。
• 本文は 72 文字で折り返し、プレーンテキストにします（リストには *／- を使用し、表は使用しません）。
• 命令形の現在形を使用します。Fix、Remove、Add のようにし、過去形や三人称形は使用しません。
• 意味のあるヘッダーにします。bugfix のような汎用的な単語は使用しません。
• 本文では WHAT より WHY を優先します。
• タグは変更の意図に合わせ、ヘッダーごとに 1 つだけ使用します。
• PR UI でヘッダーが省略記号付きで切り詰められないようにします。
• 参照情報（task-*、Fixes #、Closes #、opw-*）は末尾に記載します。
• [MIG] は OCA 固有のタグです。プロジェクトの慣例で認められている場合にのみ使用します。

ルールに違反している場合は、メッセージを修正してから返してください。

タグ選択ルール

コミットには、メインタグを 1 つだけ選択してください。

• [FIX] バグ修正
• [REF] 大規模なリファクタリング／大幅な書き換え
• [ADD] 新しいモジュールの追加
• [REM] 不要なコード／リソース／モジュールの削除
• [REV] 以前のコミットの取り消し
• [MOV] 履歴上の意図を保ったファイル／コードの移動
• [REL] リリースコミット
• [IMP] 段階的な改善
• [MERGE] マージ／フォワードポートの統合コミット
• [CLA] 個人コントリビューターのライセンス署名
• [I18N] 翻訳の更新
• [PERF] パフォーマンスの改善
• [CLN] クリーンアップ
• [LINT] リントの実施
• [MIG] モジュールの移行（プロジェクトの慣例で認められている場合のみ）

判断の指針：

• ファイルの種類ではなく、意図を最もよく表すタグを優先します。
• 明らかに移行である場合は、[MIG] を使用します。
• 移行中のリグレッションを修正する場合は、可能であればコミットを 2 つに分けます。
• 1 つのヘッダーに複数のタグを重ねて使用しないでください。

モジュール名のルール

• マーケティング上または機能上の表示名ではなく、技術的なモジュール名を使用します。
• 複数のモジュールに変更を加える場合は、簡潔に列挙するか、various を使用します。
• 1 つのコミットには論理的な変更を 1 つだけ含めることを優先し、複数のモジュールにまたがる大規模なコミットは避けてください。

良い例

[FIX] website: remove unused alert div

Fix the look of input-group-btn.
Bootstrap requires input-group-btn to be the first or last child.
An invisible alert node broke that structure and produced visual issues.

Fixes #22769
Closes #22793

[FIX] various: resolve rounding issues in currency conversions

Address inconsistent decimal rounding behavior across multiple reporting
and accounting modules. Instead of allowing components to do ad-hoc
rounding, enforce standard decimal precision in the core tools.

ticket-10928
[NO CI]

[IMP] web: add module system to web client

Introduce a module system for JavaScript code to improve isolation,
load order control, and maintainability as the client grows.

[MIG] stock_account: migrate valuation hooks to 19.0

Align valuation hook signatures with 19.0 API to preserve extension
compatibility and avoid runtime errors during upgrade.

task-8421

避けるべきパターン

次のようなメッセージは却下し、書き直してください。

• 汎用的なヘッダー（bugfix、improvements）
• モジュール名がない
• 根拠がない
• ヘッダーの動詞が過去形または三人称形
• 1 つのメッセージに複数のトピックを詰め込んだ大規模なコミット
• ヘッダーが長すぎるため、先頭行が ... で切り詰められている

応答の動作

コミットメッセージの作成を求められた場合：

1. 説明を求められない限り、生のコミットメッセージだけを返してください（コードフェンスは付けません）。
2. 情報が不足している場合は、必要最小限の確認質問だけをしてください。
3. ユーザーが下書きを提示した場合は、Odoo の規約に準拠するよう修正して返してください。
4. 厳格に対応してください。ヘッダーが Tag Selection Rules のタグ選択ルールにある大文字の角括弧付きタグで始まっていない場合は、書き直してから返してください。
5. IDE のソース管理で使用する場合は、ソース管理のコミットボックスにそのまま挿入できる、すぐに使えるコミットメッセージの候補を返してください（前置き、ラベル、Markdown は付けません）。
6. 実行の申し出：生成したコミットメッセージを提示した後、ユーザーに代わってコミットを実行することを積極的に申し出てください。コミットを実行する前に、必ずユーザーの明示的な確認を求めてください。安全に実行するため、コミットメッセージ全体を一時ファイルに書き込み、git commit --file=<tmpfile> を実行してください（その後、一時ファイルを削除します）。ユーザーが指定したテキストをシェルコマンドの引数（-m）に展開してはいけません。これにより、シェルのメタ文字が注入されるのを防げます。コミットを自動的に実行してはいけません。

使用例

• 新しいメッセージ： ユーザーがモジュール、意図、背景を提示 → WHY の本文と参照を含む [TAG] module: summary を作成します。
• 下書きの書き直し： ユーザーが fixed stuff のような不適切なメッセージを提示 → 受け入れられない旨を伝え、必要最小限の確認質問をして、修正版を返します。
• タグの選択： ユーザーが [MIG] と [FIX] のどちらにするか迷っている → 主な意図に基づいて推奨し、両方に当てはまる場合は分割を提案します。