mirror of
https://gitee.com/johng/gf
synced 2026-06-06 02:25:47 +08:00
chore(ci): add AI prompt for automated commit and push workflow
This commit is contained in:
118
.github/prompts/gf.commit-push.prompt.md
vendored
Normal file
118
.github/prompts/gf.commit-push.prompt.md
vendored
Normal file
@ -0,0 +1,118 @@
|
||||
---
|
||||
description: "自动整理当前分支修改内容,生成符合规范的commit message,并执行git add、commit和push操作"
|
||||
agent: "agent"
|
||||
tools:
|
||||
['gitkraken/*']
|
||||
---
|
||||
|
||||
# Git 提交和推送任务
|
||||
|
||||
## 任务目标
|
||||
|
||||
自动分析当前 Git 分支的修改内容,生成符合项目规范的 commit message,并完成代码的提交和推送。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
### 1. 查看当前修改状态
|
||||
|
||||
首先执行 `git status` 命令查看当前工作区的修改状态,了解哪些文件被修改、新增或删除。
|
||||
|
||||
### 2. 分析修改内容
|
||||
|
||||
根据 `git diff` 和 `git status` 的输出,分析本次修改的主要内容:
|
||||
- 识别修改的文件和模块
|
||||
- 理解修改的类型(bug修复、新功能、重构、文档更新等)
|
||||
- 识别影响的组件或包(如 `os/gtime`、`net/ghttp` 等)
|
||||
- 总结修改的核心内容
|
||||
|
||||
### 3. 生成 Commit Message
|
||||
|
||||
根据修改内容,生成符合以下规范的 commit message:
|
||||
|
||||
#### Commit Message 格式规范
|
||||
|
||||
格式:`<type>[optional scope]: <description>`
|
||||
|
||||
例如:`fix(os/gtime): fix time zone issue`
|
||||
|
||||
#### Type 类型说明
|
||||
|
||||
- `fix`: 修复了一个bug,通常会对应有一个issue
|
||||
- `feat`: 新增了一个功能,或者对现有组件执行了一些功能改进
|
||||
- `build`: 修改项目构建系统,例如修改依赖库、外部接口或者升级 Node 版本等
|
||||
- `ci`: 修改持续集成流程,例如修改 Travis、Jenkins 等工作流配置
|
||||
- `docs`: 修改文档,例如修改 README 文件、API 文档等
|
||||
- `style`: 修改代码的样式,例如调整缩进、空格、空行等
|
||||
- `refactor`: 重构代码,例如修改代码结构、变量名、函数名等
|
||||
- `perf`: 优化性能,例如提升代码的性能、减少内存占用等
|
||||
- `test`: 修改测试用例,例如添加、删除、修改代码的测试用例等
|
||||
- `chore`: 对非业务性代码进行修改,例如修改构建流程或者工具配置等
|
||||
|
||||
#### Scope 范围说明
|
||||
|
||||
- 在 `<type>` 后的括号中填写受影响的包名或范围
|
||||
- 例如:`(os/gtime)`、`(net/ghttp)`、`(database/gdb)` 等
|
||||
- 如果影响多个组件,选择主要影响的组件,或使用更通用的范围
|
||||
|
||||
#### Description 描述说明
|
||||
|
||||
- 冒号后使用动词时态 + 短语
|
||||
- 冒号后的动词小写
|
||||
- 不要有结尾句号
|
||||
- 标题尽量保持简短,最好在 76 个字符或更短
|
||||
- 使用英文描述
|
||||
|
||||
#### 完整示例
|
||||
|
||||
```text
|
||||
fix(os/gtime): fix time zone issue
|
||||
feat(net/ghttp): add middleware support for request validation
|
||||
docs(README): update installation instructions
|
||||
refactor(database/gdb): improve connection pool management
|
||||
test(container/garray): add unit tests for sorted array
|
||||
```
|
||||
|
||||
### 4. 执行 Git 操作
|
||||
|
||||
按照以下顺序执行 git 操作:
|
||||
|
||||
1. **git add -A**
|
||||
- 将所有修改的文件添加到暂存区
|
||||
|
||||
2. **git commit -m "commit message"**
|
||||
- 使用生成的 commit message 提交代码
|
||||
- 确保 commit message 符合上述规范
|
||||
|
||||
3. **git push**
|
||||
- 将本地提交推送到远程仓库
|
||||
- 如果是首次推送新分支,使用 `git push -u origin <branch-name>`
|
||||
|
||||
## 注意事项
|
||||
|
||||
1. **冲突处理**:如果push时遇到冲突,需要先执行 `git pull` 解决冲突后再推送
|
||||
|
||||
2. **分支检查**:确认当前在正确的分支上进行操作
|
||||
|
||||
3. **提交范围**:确保只提交相关的修改,避免混入无关的文件
|
||||
|
||||
4. **Commit Message 质量**:
|
||||
- 确保描述准确、简洁
|
||||
- 类型选择要正确
|
||||
- 范围要明确
|
||||
- 描述要有意义,避免模糊的描述如 "update code"
|
||||
|
||||
5. **相关 Issue**:
|
||||
- 如果有对应的 issue,在 commit message body 中添加 `Fixes #1234` 或 `Updates #1234`
|
||||
- 完全修复使用 `Fixes`,部分修复使用 `Updates`
|
||||
|
||||
## 输出要求
|
||||
|
||||
完成所有操作后,提供以下信息:
|
||||
- 生成的commit message
|
||||
- 执行的git命令及其输出
|
||||
- 推送结果(成功/失败)
|
||||
- 如有问题或建议,给出相应的提示
|
||||
|
||||
## 参考文档
|
||||
|
||||
- [项目PR模板](../../.github/PULL_REQUEST_TEMPLATE.MD)
|
||||
37
.github/prompts/gf.update-comments.prompt.md
vendored
Normal file
37
.github/prompts/gf.update-comments.prompt.md
vendored
Normal file
@ -0,0 +1,37 @@
|
||||
---
|
||||
description: "主动整理源码的注释信息,补充不完整的注释内容,更新和修正过时的、不准确的注释内容,以提升代码的可读性和维护性。"
|
||||
agent: "agent"
|
||||
---
|
||||
|
||||
# 源码注释更新规范及要求
|
||||
|
||||
- 补充不完整的注释内容,确保每个函数、方法、类、模块等都有清晰、准确的注释说明其功能和用途。
|
||||
- 对于具体函数实现中,如果存在较复杂的逻辑或算法,需要对这部分源码提供详细的注释说明,帮助理解代码实现。
|
||||
- 更新和修正过时的、不准确的注释内容,确保注释与代码逻辑保持一致。
|
||||
- 使用统一的注释风格和格式,遵循项目的编码规范。
|
||||
- 确保注释内容简洁明了,避免冗长和复杂的描述。
|
||||
- 在注释中包含必要的参数说明、返回值说明和异常处理信息。
|
||||
- 在更新注释时,注意代码的可读性和维护性,确保注释能够帮助开发者更好地理解和使用代码。
|
||||
- 在完成注释更新后,进行代码审查,确保注释内容符合规范要求,并且没有遗漏重要信息。
|
||||
- 特别是审查函数中已有的注释的准确性,避免只补充了缺失的注释内容,而忽略了对已有注释内容的更新和修正。
|
||||
|
||||
|
||||
# 组件源码文件整理
|
||||
|
||||
- 源码仓库目录地址为:${fileDirname}/../..
|
||||
- 检索当前仓库源码的所有代码文件,按照组件维度进行分类整理,整理成类似于以下任务形式,以便于后续按照任务形式处理源码文件:
|
||||
```markdown
|
||||
- net/ghttp
|
||||
- [ ] ghttp_func.go
|
||||
- [ ] ghttp_server.go
|
||||
```
|
||||
- 将以上任务内容写入到任务文件,任务文件目录路径为:如:${fileDirname}/../../temp ,任务文件名称格式为:当前最新版本号-comments-update-tasks.md ,例如:v2.8.0-comments-update-tasks.md,以便于AI Agent根据任务逐步整理源码文件注释内容。
|
||||
- 如果该版本的任务文件已经存在,则不需要重复创建任务文件,直接使用已有的任务文件即可。
|
||||
|
||||
|
||||
# 源码文件处理策略
|
||||
|
||||
- 按照组件维度创建处理任务,比如如果梳理出有30个组件,那么则创建30个任务跟进处理。
|
||||
- 按照任务文件以及注释规范逐步更新源码文件注释内容,更新完成后,更新对应任务的任务标记为已完成状态。
|
||||
- 每处理完成一个源码文件,需要审查是否存在缺漏的注释内容,避免只处理了一部分源码的注释。例如,如果源码文件中存在50个函数,那么需要审查这50个函数的注释内容是否都已经补充完整并且注释符合规范要求,避免只补充了其中20个函数的注释内容。
|
||||
|
||||
Reference in New Issue
Block a user