mcpField
O
odoo-commit-message-guidelines

odoo-commit-message-guidelines

github.com/grupoyacck开发061 次安装2 周前更新
代码仓库

关于 odoo-commit-message-guidelines

面向 Odoo 代码贡献者的提交信息编写与校验技能，帮助生成便于审阅和回退的英文提交说明。它根据变更意图选择标签，并按规定组织标题、正文和引用。

主要功能

  1. 01收集模块、原因与引用信息
  2. 02按变更意图选择提交标签
  3. 03检查标题格式与长度
  4. 04按要求编排英文正文
  5. 05校验引用与 CI 指令位置

适用场景

  1. 01为 Odoo 代码撰写提交信息
  2. 02改写不符合规范的提交说明
  3. 03检查提交标签和格式

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/grupoyacck/gy-agent-skills --skill odoo-commit-message-guidelines

安装后在 Claude Code 中输入/odoo-commit-message-guidelines确认已加载。

附带文件references/CONTRIBUTING.mdreferences/git_guidelines.md

详细介绍

Odoo 提交消息指南

目的

使用此技能编写高质量的 Odoo 提交消息，使其风格一致、便于审查且易于回滚。

本地参考资料

  • references/git_guidelines.md — 标题判断原则和 WHY 优先于 WHAT 的理念
  • 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 这类泛泛的词。
  • 正文优先说明 WHY，而不是 WHAT。
  • 标签必须与变更意图相符；每个标题只能使用一个标签。
  • 标题在 PR 界面中不得被截断并显示省略号。
  • 引用（task-*、Fixes #、Closes #、opw-*）放在末尾。
  • [MIG] 是 OCA 专用标签；仅在项目惯例支持时使用。

如果有任何规则不符合，先重写消息再返回。

标签选择规则

为提交选择且仅选择一个主要标签：

  • [FIX] 修复错误
  • [REF] 重大重构 / 大规模改写
  • [ADD] 添加新模块
  • [REM] 移除无用代码/资源/模块
  • [REV] 回滚先前提交
  • [MOV] 移动文件/代码，同时保留历史意图
  • [REL] 发布提交
  • [IMP] 渐进式改进
  • [MERGE] 合并 / 前向移植集成提交
  • [CLA] 个人贡献者许可签名
  • [I18N] 翻译更新
  • [PERF] 性能改进
  • [CLN] 清理
  • [LINT] 代码检查
  • [MIG] 模块迁移（仅在项目惯例支持时使用）

选择指导：

  • 优先选择最能体现变更意图的标签，而非文件类型。
  • 如果明确属于迁移，请使用 [MIG]。
  • 如果迁移过程中修复了回归问题，尽可能拆分为两个提交。
  • 避免在一个标题中堆叠多个标签。

模块命名规则

  • 使用技术模块名称，而非营销/功能展示名称。
  • 如果涉及多个模块，简要列出它们或使用 various。
  • 每个提交尽量只包含一个逻辑变更，避免大型跨模块提交。

良好示例

[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. 除非用户要求解释，否则仅返回原始提交消息（不要使用代码围栏）。
  2. 如果缺少信息，只询问必要的澄清问题。
  3. 如果用户提供了草稿，返回符合 Odoo 规范的修正版。
  4. 严格遵守：如果标题不是以 Tag Selection Rules 中的一个大写方括号标签开头，则在返回前重写。
  5. 对于 IDE 的源代码管理用法，返回可直接插入源代码管理提交框的提交消息建议（不加前言、标签或 Markdown）。
  6. 执行提议：提供生成的提交消息后，主动提出代用户执行提交。运行提交前务必征得用户明确确认。为确保安全，将完整提交消息写入临时文件，然后运行 git commit --file=<tmpfile>（之后删除临时文件）。绝不将用户提供的文本插入 shell 命令参数（-m）中，以避免 shell 元字符注入。不得自动执行提交。

用法示例

  • 新建消息： 用户提供模块、意图和背景 → 起草 [TAG] module: summary，并包含说明原因的正文和引用。
  • 重写草稿： 用户提供诸如 fixed stuff 这样的不合格消息 → 拒绝并询问必要的澄清问题，然后返回修正版。
  • 选择标签： 用户不确定该选 [MIG] 还是 [FIX] → 根据主要意图给出建议；如果两者都适用，则建议拆分。

评论

支持 Markdown