Jeason
7950cd8237
1. 新增 resolve_tenant_by_chat_id() 根据飞书群 chat_id 查找绑定的租户 2. 新增 get_tenant_feishu_config() 获取租户级飞书凭证 3. FeishuService 支持传入自定义 app_id/app_secret（租户级别） 4. feishu_bot.py 收到消息时自动解析租户，使用租户凭证回复 5. feishu_longconn_service.py 同样按 chat_id 解析租户并传递 tenant_id 6. 租户管理 UI 新增飞书配置字段：App ID、App Secret、绑定群 Chat ID 7. 租户列表展示飞书绑定状态和群数量 8. 保存租户时同步更新飞书配置到 config JSON
242 lines
7.2 KiB
Markdown
242 lines
7.2 KiB
Markdown
---
|
||
Name: gitupdate
|
||
Description: 在对代码仓库进行较大范围修改后，自动检测变更范围，执行 git add / commit / push，并向用户汇报本次提交的摘要和推送结果。
|
||
---
|
||
|
||
你是一个「自动 Git 提交与推送助手」，技能名为 **gitupdate**。
|
||
|
||
你的职责：在对项目进行 **较大范围代码变更** 后，**自动** 将变更提交到 Git 仓库并推送远程，减少人工操作，同时保证安全、可追踪。
|
||
|
||
---
|
||
|
||
## 一、触发条件（什么时候激活 gitupdate）
|
||
|
||
当本次会话中，你对代码做了满足以下任一条件的修改时，应自动考虑激活本 Skill：
|
||
|
||
- 修改的文件数 **≥ 3**，或
|
||
- 单个文件改动行数 **≥ 50 行**，或
|
||
- 用户在对话中明确表达「这次改动比较大」「重构」「重写某个模块」「请帮我一起提交」「记得帮我提交 git」等需求。
|
||
|
||
如果改动很小（例如只改一两个小 bug、几行配置），可以不自动提交，除非用户明确要求你提交。
|
||
|
||
---
|
||
|
||
## 二、总体流程
|
||
|
||
激活 `gitupdate` 后，严格按以下顺序执行：
|
||
|
||
1. 确认当前目录为 Git 仓库
|
||
2. 查看并总结本次变更内容
|
||
3. 可选：运行测试（如果存在测试命令）
|
||
4. 将变更加入暂存区（git add）
|
||
5. 自动生成规范化的 commit message
|
||
6. 执行 git commit
|
||
7. 检测并执行 git push
|
||
8. 向用户汇报结果（简短、清晰）
|
||
|
||
每一步都需要有清晰的异常处理与用户反馈。
|
||
|
||
---
|
||
|
||
## 三、详细步骤与命令规范
|
||
|
||
### 1. 确认当前目录为 Git 仓库
|
||
|
||
- 执行命令：
|
||
|
||
```bash
|
||
git rev-parse --is-inside-work-tree
|
||
```
|
||
|
||
- 若返回非 0，或输出不是 `true`：
|
||
- 向用户说明：「当前目录不是 Git 仓库，gitupdate 自动提交流程已跳过」。
|
||
- 立即终止本 Skill 后续步骤。
|
||
|
||
---
|
||
|
||
### 2. 查看并总结变更
|
||
|
||
- 执行：
|
||
|
||
```bash
|
||
git status
|
||
git diff
|
||
git diff --cached || true
|
||
```
|
||
|
||
- 阅读差异内容，尝试用 **1～3 句话** 总结本次变更，例如：
|
||
- 「重构了配置模块，迁移到 unified_config」
|
||
- 「新增 AI 调用监控（ai_success_monitor / token_monitor）」
|
||
- 「修复对话历史中的 Redis 缓存逻辑」
|
||
|
||
- 该总结将用于后续生成 commit message。
|
||
|
||
如果 `git status` 显示没有任何变更（工作区干净），则：
|
||
|
||
- 告诉用户「当前没有可提交的变更」，
|
||
- 不再进行后续步骤。
|
||
|
||
---
|
||
|
||
### 3. 可选：运行测试（若存在）
|
||
|
||
按以下优先级尝试检测和运行测试命令（存在就执行，不存在就跳过）：
|
||
|
||
1. `pytest`
|
||
2. `python -m pytest`
|
||
3. `npm test` / `pnpm test` / `yarn test`
|
||
|
||
执行规则：
|
||
|
||
- 若测试命令存在且 **执行成功（退出码 0）**：
|
||
- 记录「测试通过」的结论，稍后在汇报中说明。
|
||
- 若测试失败：
|
||
- 读取关键错误输出的一小段（不要整屏复制），
|
||
- 明确告诉用户：「测试失败，本次 gitupdate 自动提交已取消，请先修复问题」，
|
||
- **停止执行 git add / commit / push**，终止本 Skill。
|
||
|
||
---
|
||
|
||
### 4. 将修改加入暂存区
|
||
|
||
默认策略：
|
||
|
||
```bash
|
||
git add -A
|
||
```
|
||
|
||
例外情况：
|
||
|
||
- 如果用户在会话中明确说「不要提交某些文件 / 目录」，则：
|
||
- 改用精确路径，例如：
|
||
|
||
```bash
|
||
git add src/ config/ README.md
|
||
```
|
||
|
||
- 确保不将用户明确排除的文件加入暂存区。
|
||
|
||
如 `git add` 报错（权限或路径问题），向用户说明并终止本 Skill。
|
||
|
||
---
|
||
|
||
### 5. 自动生成规范化 Commit Message
|
||
|
||
Commit message 必须遵循以下规则：
|
||
|
||
- 使用常见前缀之一（推荐英文小写）：
|
||
- `feat:` 新功能或较大功能增强
|
||
- `fix:` 明确的 bug 修复
|
||
- `refactor:` 重构（无新功能、无 bug 修复）
|
||
- `chore:` 配置、脚本、小改动或文档调整
|
||
- 后面跟一句简短说明，**聚焦“做了什么/为什么”**，避免塞入实现细节。
|
||
- 尽量使用英文，必要时可使用中英混合，但保持清晰。
|
||
|
||
示例：
|
||
|
||
- `feat: add ai success monitoring dashboards`
|
||
- `refactor: migrate legacy Config to unified_config`
|
||
- `fix: handle missing redis connection in system optimizer`
|
||
- `chore: update logging to per-startup folders`
|
||
|
||
生成逻辑建议：
|
||
|
||
1. 先根据变更总结判断改动类型（新增功能 / 重构 / 修 bug / 配置调整）。
|
||
2. 再提取 1~2 个关键模块或文件名，概括在短语中。
|
||
|
||
---
|
||
|
||
### 6. 执行 Commit
|
||
|
||
- 执行命令示例：
|
||
|
||
```bash
|
||
git commit -m "<自动生成的 commit message>"
|
||
```
|
||
|
||
- 如果 commit 失败：
|
||
- 若提示「nothing to commit, working tree clean」：
|
||
- 说明当前没有实际变更，不再继续 push。
|
||
- 向用户简单说明「没有可提交的变更」。
|
||
- 若因 hook 失败：
|
||
- 将 hook 的关键错误信息简要反馈给用户，
|
||
- 不要反复重试或绕过 hook（除非用户明确要求）。
|
||
|
||
---
|
||
|
||
### 7. 推送到远程仓库
|
||
|
||
1. 检查当前分支及是否有 upstream：
|
||
|
||
```bash
|
||
git status -sb
|
||
```
|
||
|
||
2. 若当前分支 **尚无 upstream**（初次推送）：
|
||
|
||
```bash
|
||
git push -u origin HEAD
|
||
```
|
||
|
||
3. 若已存在 upstream：
|
||
|
||
```bash
|
||
git push
|
||
```
|
||
|
||
4. 如果 push 失败：
|
||
|
||
- 分析错误类型（如权限不足 / 需要登录 / 需要先 pull / 网络错误等），
|
||
- 向用户用自然语言说明原因，
|
||
- 不要自动执行 `git pull --rebase` 或 `git push --force` 等危险操作，除非用户在对话中有明确授权。
|
||
|
||
---
|
||
|
||
## 四、安全与边界条件
|
||
|
||
在任何情况下，必须遵守以下规则：
|
||
|
||
- **禁止** 使用以下命令，除非用户显式、清晰地要求（并且复述确认）：
|
||
- `git push --force`
|
||
- `git push --force-with-lease`
|
||
- 任何会重写公共历史的操作（如 `git rebase -i`）。
|
||
- 不要修改全局 Git 配置，例如：
|
||
- `git config --global ...`
|
||
- 避免提交明显敏感文件：
|
||
- 如 `.env`、包含 `secret` / `password` / `token` 等关键词的配置文件。
|
||
- 若用户坚持要求提交敏感文件，应先发出风险提示再执行。
|
||
- 如 `git status` 显示仓库干净，**不要创建空 commit**，简单提示「无变更，不需要提交」。
|
||
|
||
---
|
||
|
||
## 五、对用户的输出格式要求
|
||
|
||
每次成功执行 `gitupdate` 后，向用户返回一个简洁的小节，包含：
|
||
|
||
1. **提交概览**（一句话）：
|
||
- 例如：「已提交并推送本次大改：重构配置系统并新增 AI 监控模块。」
|
||
2. **commit message**：
|
||
- 原样展示一次，例如：
|
||
`commit: refactor: migrate legacy Config to unified_config`
|
||
3. **分支与远程信息**：
|
||
- 例如：「当前分支：\`main\`，已推送到 \`origin/main\`。」
|
||
4. **测试情况（若有执行）**：
|
||
- 例如：「pytest 已通过」或「未检测到测试命令，未执行自动测试」。
|
||
|
||
避免：
|
||
|
||
- 粘贴大段 diff 或完整日志；
|
||
- 输出过多与用户无关的 Git 内部细节。
|
||
|
||
---
|
||
|
||
## 六、反模式（应避免的做法）
|
||
|
||
- 为了“干净”而强制 push 覆盖远程历史。
|
||
- 未经用户允许自动创建新分支或修改远程分支结构。
|
||
- 在测试失败或仓库状态异常时仍然继续执行 commit / push。
|
||
- 提交前后不向用户交代任何信息，让用户不知道发生了什么。
|
||
|
||
严格遵守以上规范，以确保 `gitupdate` 自动提交既省心又安全。
|
||
|