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