125 lines
5.2 KiB
Markdown
125 lines
5.2 KiB
Markdown
---
|
||
name: commit-convention
|
||
description: 为本仓库生成符合团队规范的 Git 提交信息，并在用户要求提交代码时执行完整提交流程。用于 git commit、提交代码、写 commit message、创建提交、push 前整理提交等场景；须根据变更来源选用 [Ai] 或 [Human] 标记并写清业务变更。
|
||
---
|
||
|
||
# Git 提交规范（Agent 协助提交）
|
||
|
||
## 触发条件
|
||
|
||
满足任一条件，**必须先加载本 skill**，再执行 `git add` / `git commit`：
|
||
|
||
- 用户明确要求：提交、commit、git commit、保存提交、push 前先 commit 等
|
||
- 用户规则中的「committing-changes-with-git」流程已启动
|
||
|
||
**未获用户明确授权时，不得执行 commit。**
|
||
|
||
---
|
||
|
||
## 提交来源标记（强制）
|
||
|
||
所有由 Agent 代为执行的 `git commit`，subject **必须**以 `[Ai]` 或 `[Human]` 开头（二选一，不得省略）。
|
||
|
||
```text
|
||
[Ai] <type>(<scope>): <subject>
|
||
[Human] <type>(<scope>): <subject>
|
||
|
||
<body 可选：业务背景、影响范围、关联 Bug>
|
||
```
|
||
|
||
- `type`：`feat` | `fix` | `refactor` | `style` | `perf` | `chore` | `docs` | `test` | `build` | `ci`
|
||
- `scope`：模块/页面，如 `benefits`、`mine`、`community`、`player`
|
||
- 仅当标记为 `[Ai]` 时，可在正文末尾追加 trailer（可选）：
|
||
|
||
```text
|
||
Co-Authored-By: Cursor <noreply@cursor.com>
|
||
```
|
||
|
||
### 如何判定用 `[Ai]` 还是 `[Human]`
|
||
|
||
在撰写 message **之前**，结合 `git diff` 与**当前对话上下文**判断本次待提交变更的**主要作者**：
|
||
|
||
| 标记 | 适用场景 |
|
||
|------|----------|
|
||
| **`[Ai]`** | 本次待提交 diff 中的逻辑/样式/配置变更，**主要由当前或近期 Agent 会话编写或修改**；或用户未说明来源且 diff 与对话中 Agent 已完成的实现一致 |
|
||
| **`[Human]`** | 变更**主要由用户本人编写**（用户仅让 Agent 代写 commit message、执行 add/commit）；或用户明确说「人工提交」「我自己改的」「帮我提交一下（我改的）」等 |
|
||
|
||
**判定步骤（按序执行）：**
|
||
|
||
1. 用户是否**明确**要求 `[Human]` / 人工提交？→ 是则用 `[Human]`（除非 diff 明显全是 Agent 刚写的，此时先向用户确认）
|
||
2. 当前对话里，Agent 是否**为实现用户需求**而修改了待提交文件？→ 是则用 `[Ai]`
|
||
3. 待提交文件是否**未出现在**本对话的 Agent 编辑记录中，且用户只是要求「提交一下」？→ 用 `[Human]`
|
||
4. **同一批 staged 变更**中既有 Agent 编写又有用户手写：优先**询问是否拆分**为两次提交；若用户坚持一次提交，以**改动行数/核心逻辑**更多的一方为准，并在 body 中简要说明混合来源
|
||
5. **无法判断**时：默认 `[Ai]`，并在执行 commit 前**用一句话向用户说明**所选标记及理由；若用户纠正，改用 `[Human]` 后重新 commit（hook 失败则新建 commit，勿 amend 除非符合 user rule）
|
||
|
||
**禁止：**
|
||
|
||
- 用户明确是人工改动时，仍标 `[Ai]`
|
||
- 用户未授权时，将 Agent 刚写完的代码标 `[Human]`
|
||
|
||
---
|
||
|
||
## Subject 质量（强制）
|
||
|
||
提交说明必须让人一眼看懂**改了什么业务**或**修了什么问题**。
|
||
|
||
### 必须做到
|
||
|
||
1. 先并行执行：`git status`、`git diff`（含 staged）、`git log -5 --oneline` 了解风格与变更范围
|
||
2. **完成上一节来源判定**，选定 `[Ai]` 或 `[Human]`
|
||
3. subject 用**完整语义**描述，优先中文；可中英混用 scope
|
||
4. 多文件、多模块时：一条 commit 只包同一业务目标；若混杂无关改动，先询问是否拆分
|
||
5. body 写：原因、用户可见变化、风险点（如有）；混合来源时在 body 注明
|
||
|
||
### 严禁（subject 不得仅为或等同于）
|
||
|
||
`test`、`修改`、`update`、`fix`、`xxx`、`111`、`wip`、`temp`、`提交`、`save`、纯标点、纯数字、单字
|
||
|
||
### 示例
|
||
|
||
```text
|
||
# ✅ Agent 实现的功能
|
||
[Ai] feat(benefits): 新增七日签到弹窗与连续签到奖励展示
|
||
[Ai] fix(player): 修复横屏切换后 HLS 首帧黑屏
|
||
|
||
# ✅ 用户手写，Agent 仅代提交
|
||
[Human] style(home): 调整首页 Header 搜索框间距与图标尺寸
|
||
[Human] fix(lazyImg): 修复弱网下占位图闪烁
|
||
|
||
# ❌
|
||
feat(benefits): 新增签到弹窗 # 缺少来源标记
|
||
[Ai] fix: 修改
|
||
修改播放器
|
||
111
|
||
```
|
||
|
||
---
|
||
|
||
## 提交流程（与 user rule 对齐）
|
||
|
||
1. `git status` + `git diff` + `git log`（可并行）
|
||
2. **判定** `[Ai]` / `[Human]`（见上表）
|
||
3. 根据 diff **撰写**符合本规范的 message（HEREDOC 传 `-m`）
|
||
4. 只 `git add` 与本次任务相关的文件
|
||
5. **不得**提交 `.env`、密钥、凭据类文件；若用户在 staged 中含此类文件，警告并排除
|
||
6. `git commit` 后 `git status` 确认成功
|
||
7. hook 失败时：**不要** `commit --amend`，修 message 后**新建 commit**
|
||
8. **除非用户明确要求，否则不 `git push`**
|
||
|
||
---
|
||
|
||
## 输出给用户
|
||
|
||
提交完成后简要说明：
|
||
|
||
- **来源标记**：`[Ai]` 或 `[Human]`，以及一行判定理由
|
||
- commit hash（若有）
|
||
- 本次纳入的文件范围
|
||
- message 摘要（一行）
|
||
|
||
---
|
||
|
||
## 与本地 Hook / CI 的关系
|
||
|
||
本 skill 约束 **Agent 行为**。若仓库后续接入 `husky` + `commitlint` 或 CI，以仓库脚本校验为准；Agent 仍须预先满足 `[Ai]`/`[Human]` 与 subject 质量，避免 hook 拒绝。
|