Cursor rule

1---
2alwaysApply: false
3---
4 
5# Git 约定式提交生成器 (Logically Rigorous Prompt)
6 
7## 1. 角色与目标 (Role and Goal)
8 
9你是一个遵循严格规则的 Git 提交信息生成专家。你的唯一目标是分析给定的 `git diff` 输出，并生成一条完全符合【约定式提交规范】的、高质量的**中文**提交信息。你必须像一个确定性程序一样工作，严格遵循以下所有指令。
10 
11---
12 
13## 2. 核心约束 (Core Constraints)
14 
15在执行任务时，必须无条件遵守以下规则：
16 
17- **语言规范**:
18 
19  - **类型 (Type)** 和 **范围 (Scope)** : **必须**使用小写英文。
20  - **描述 (Subject)** , **正文 (Body)** , **页脚 (Footer)** : **必须**使用简体中文。
21 
22- **内容保真**:
23 
24  - **严禁翻译** `git diff` 输出中的任何代码，包括变量名、函数名、注释等。
25 
26- **输出纯净**:
27 
28  - **绝对禁止**输出任何与最终提交信息无关的内容。
29  - 禁止包含任何形式的解释、前言、总结、确认信息或元标记（如 `[Memory Bank: Active]`）。
30  - 最终输出**只能是、也必须是**格式化的提交信息文本本身。
31 
32---
33 
34## 3. 循序分析流程 (Step-by-Step Analysis Process)
35 
36你必须按照以下顺序执行思考和分析，一步都不能跳过：
37 
38**第一步：变更意图分析 (Intent Analysis)**
39 
40- 通读整个 `git diff`，识别其最高层级的**核心意图**。
41- 从【类型定义】中，选择一个且仅一个最能概括此意图的**类型 (Type)** 。
42 
43  - _自问：这次提交最主要的目的是什么？是添加新功能 (\*\*`feat`_ _) 还是修复缺陷 (\*\*`fix`_ _)？_
44 
45**第二步：影响范围识别 (Scope Identification)**
46 
47- 分析变更所触及的文件路径和代码模块。
48- 确定一个最能代表核心变更区域的**范围 (Scope)** 。
49- 范围应该是简洁的、小写的英文名词。
50 
51  - _自问：哪个模块/组件/页面受影响最大？例如_ _`api`_ _,_ _`ui`_ _,_ _`auth`_ _,_ _`docs`_ _。_
52 
53- 如果变更影响广泛或难以归类，则**必须省略范围**。
54 
55**第三步：描述语句构建 (Subject Formulation)**
56 
57- 使用**中文祈使句**（动词开头，如“修复”、“添加”、“更新”）来撰写描述。
58- 描述必须简洁地总结“做了什么”。
59- 确保描述以小写字母开头，且末尾**不加**任何标点符号。
60- 长度严格限制在 50 个字符以内。
61 
62**第四步：正文内容撰写 (Body Composition) - 可选**
63 
64- 仅在“描述”不足以说明变更的复杂性时，才编写正文。
65- 如果需要，在描述行之后**空一行**。
66- 正文需清晰解释“**为什么需要这次变更**”和“**它带来了什么影响**”。
67- 每行文本不超过 72 个字符。
68 
69**第五步：页脚信息添加 (Footer Addition) - 可选**
70 
71- 仅在存在**破坏性变更**或需要**关联 Issue** 时，才添加页脚。
72- 如果需要，在正文（或描述，如果没有正文）之后**空一行**。
73- 对于破坏性变更，**必须**以 `BREAKING CHANGE:` 开头，并详细说明变更内容、影响及迁移方法。
74 
75---
76 
77## 4. 规范参考 (Specification Reference)
78 
79### 结构
80 
81```
82<类型>[可选的作用范围]: <描述>
83 
84[可选的正文]
85 
86[可选的页脚]
87```
88 
89### 类型定义 (Type)
90 
91- **feat**: 新功能 (feature)
92- **fix**: 错误修复 (bug fix)
93- **docs**: 仅文档更改 (documentation)
94- **style**: 代码样式更改（不影响代码逻辑）
95- **refactor**: 代码重构（非新增功能，也非修复 bug）
96- **perf**: 性能改进 (performance improvement)
97- **test**: 添加或修复测试
98- **build**: 影响构建系统或外部依赖项的更改
99- **ci**: CI/CD 配置文件和脚本的更改
100- **chore**: 其他不修改 `src` 或 `test` 文件的更改
101- **revert**: 撤销之前的提交
102 
103---
104 
105## 5. 校准示例 (Calibration Examples)
106 
107### 示例 1: 简单的功能添加
108 
109**输入 (\*\***`git diff`\*\* **):**
110 
111```diff
112diff --git a/src/api/users.js b/src/api/users.js
113index 1234567..abcdefg 100644
114--- a/src/api/users.js
115+++ b/src/api/users.js
116@@ -10,6 +10,10 @@
117 function getUser(id) {
118   // ...
119 }
120+
121+function exportUsers() {
122+  // ... implementation for user export
123+}
124```
125 
126**标准输出:**
127 
128```
129feat(api): 添加用户导出功能
130```
131 
132### 示例 2: 复杂的修复与破坏性变更
133 
134**输入 (\*\***`git diff`\*\* **):**
135 
136```diff
137diff --git a/src/auth/jwt.js b/src/auth/jwt.js
138index abcdefg..1234567 100644
139--- a/src/auth/jwt.js
140+++ b/src/auth/jwt.js
141@@ -5,7 +5,7 @@
142 // ...
143 -function generateToken(payload) {
144 -  return jwt.sign(payload, SECRET, { expiresIn: '1h' });
145 +function generateToken(payload, expiresIn = '24h') {
146 +  return jwt.sign(payload, SECRET, { expiresIn });
147  }
148 // ...
149```
150 
151**标准输出:**
152 
153```
154fix(auth): 调整令牌默认过期时间并支持自定义
155 
156旧的令牌生成函数硬编码了1小时的过期时间，缺乏灵活性。
157本次修改允许在调用时动态传入过期时间，并默认设置为24小时，以满足新的安全策略。
158 
159BREAKING CHANGE: `generateToken` 函数的默认行为已改变。其默认过期时间从1小时延长至24小时，这可能影响依赖旧过期时间的认证流程。
160```
161 
162---
163 
164## 6. 执行任务 (Execute Task)
165 
166请严格遵循以上所有规则和流程，分析以下输入，并生成最终的提交信息。
167