起点
“帮我生成今天的工作日报。”
一个简单的需求。AI 要从 git log、会话记录、会议纪要中汇总信息，写一篇格式规范的 markdown。一开始这就是一条指令，但随着每次使用逐步变成一份 SKILL.md。
第一版：日报 Skill
最初的日报 skill 骨架清晰，但实际使用中很快遇到三个问题。
rebase 污染日志
当工作分支 rebase 到 develop 后，develop 上的历史 commit 也会出现在 git log 中——那些 commit 根本不是今天做的，只是 rebase 重写了时间戳。
修复：加上 HEAD --not develop 过滤。
多次修正的噪音
同一个 bug 可能拆成 3 次 commit：
fix: add error check
fix: update status after tracking
fix: keep order_status unchanged逐条列在日报里没有意义。一个修复拆成多次 commit 是常态，但日报反映的是”做了什么”而不是”commit 了几次”。
修复：要求 AI 按语义合并同类 commit。
多分支视野
仅看当前分支会遗漏项目整体动态——比如合作者今天合并了什么到 develop。
修复：同时采集 feature 分支、develop 本地、origin/develop 三路日志。
第二版：Git 工作流 Skill
日报稳定后，更深层的需求浮现：AI 做 git 操作时缺乏明确规则。
之前有一套安全代理脚本，强制只能在特定分支提交、禁止 push。但代理太严了，和实际工作流脱节。于是我们完整设计了一个本地 git 工作流。
逐步收敛的设计
起点是几个原则：提交只在私有分支完成、协作分支只做合并、冲突在缓冲区解决保护主线。
然后逐层展开层级关系：
main ← develop ← feature/xxx ← local/xxx
↑
fix/xxx每一层约束都来自讨论：
- “需要 local 这层吗？” → “需要，WIP 阶段不想污染 feature/*”
- “squash merge 会丢失历史吗？” → “按语义分组压缩，不是绝对一条”
- “fix 分支也走 local 吗？” → “不，fix 单次提交，直接 commit”
- “feature 落后 develop 怎么办？” → “手动 merge develop，冲突在 feature 上解决”
最终形成完整的 SKILL.md，7 个模块覆盖完整流程。
三个关键决策
保护现场 > 自动恢复
遇到脏工作区或冲突时不做任何自动处理——不 stash、不撤销、不丢弃。停住，报告用户，等人决定。这是最高原则。
提示驱动 > 自动执行
合并、推送、同步只提示不自动。时机由开发者决定——开发中段不想被打断，快合入时不需要同步。
按语义压缩 > 按次数记录
多条 commit 合并为一条概括性描述。这是 git log 和日报之间的语义鸿沟——git 记录的是操作过程，日报反映的是工作成果。
Skill 设计三原则
- Skill 是对话的沉淀物。不要一次性设计完美。从具体问题开始，每次遇到边界情况就加一条规则。
- 规则要可执行，不是口号。“注意安全”不是好规则。“操作前先 git status，脏工作区则停止”才是。
- 经验要跨项目复用。全局 skill 对所有项目生效——这是渐进的系统优化。