teamai-cli 日常使用：push 分发、pull 同步与 SessionStart Hook 自动化

日常流转的全景图

安装接入之后，teamai-cli 的日常使用就是四个动作的循环：改配置 → push 提交 → 审核合并 → pull 同步。这和团队维护代码的流程一模一样——因为 teamai-cli 底下就是 Git，你熟悉的协作纪律全部适用。

成员A改好 Skill ──teamai push──→ 远端仓库（发起变更）
                                      │
                              MR/PR 审核合并
                                      │
其他成员 ←──SessionStart Hook 自动 pull── 本地工具目录更新

push：把本地变更提交到团队仓库

改好了本地的 Skills/Rules/配置，用 push 上交：

# 提交当前变更
teamai push

# 提交全部文件
teamai push --all

push 不是直接改仓库——它发起的是一个变更请求（在 GitHub 上走 PR，在 TGit/CNB 上走 MR），由仓库管理员审核后合并。这个设计值得单独强调：AI 配置的变更同样需要 code review。

想一想审核防的是什么：某天某人 push 了一个「好用的新 Skill」，里面夹带了会删文件的脚本；或者一段 Skills 描述里混进了会诱导 AI 生成不安全代码的指令。Skills 本质上是「给 AI 执行的指令包」，它的风险等级和代码脚本同级——没有审核的 Skills 分发等于没有 code review 的代码合入。本站在 AgentDock Skills 指南里也讲过同样的道理：能力包需要版本管理，而版本管理缺审核就是不完整的。

pull：同步团队最新配置

# 同步远端最新配置
teamai pull

# 只看会变什么，不实际改动（强烈推荐先跑这个）
teamai pull --dry-run

--dry-run 是 pull 的安全带：它列出本次同步会新增、更新、删除哪些文件。特别是当团队里有人重命名或删除了共享 Skills 时，dry-run 让你在覆盖本地之前看清影响面。

SessionStart Hook：把「手动 pull」从流程里删掉

上面两条命令解决「怎么同步」，但如果依赖每个人的自觉性，迟早有人忘了 pull、用着三个月前的旧配置。teamai-cli 的解法是 SessionStart Hook：把自动 pull 挂在 AI 工具的会话启动钩子上——Claude Code 每次启动会话时，先执行 teamai pull，再进入工作状态。

配置完成后，团队成员的心智模型简化成一句话：每次打开 Claude Code，拿到的永远是团队最新配置。 没有检查更新的动作，没有版本不一致的扯皮。

这个「靠机制不靠自觉」的思路在团队协作里反复被验证。对比一下：Cursor 用户应该熟悉 Cursor Rules 配置——规则文件改了要手动确认生效；teamai 的 Hook 方案把这一步也自动化了。

status / list：日常健康检查

# 本地与远端的差异
teamai status

# 已安装的全部技能清单
teamai list

# 成员管理视图
teamai members

# 看某个技能的描述与内容
teamai skill show <技能名>

# 排除某个不想被同步的技能
teamai skill exclude add <技能名>
teamai skill exclude remove <技能名>

skill exclude 是一个实用的小功能：团队仓库里某个技能不适合你的场景（比如你不用某个特定工具），把它加进排除清单，pull 时不再同步——不用为了个人偏好去动团队共享配置。

一套推荐的团队日常节奏

发现好东西：随手 push，配一句清晰的变更说明（未来翻 Git log 时你会感谢自己）
每周一次：管理员过一遍本周的变更历史，清理没人用的 Skills——和本站写五人舰队时的清理纪律一样，冗余是悄悄发生的
新人入职：init + Hook 配好，团队积累的所有 Skills 和规范即刻到位——这是 teamai-cli 在「新人上手」环节最直观的收益
有人离职：他贡献的知识已经沉淀在仓库里，人走了经验留下

push/pull 命令速查表

日常流转的全部命令，按「写入 → 读取 → 检查」三组整理：

命令	方向	作用
`teamai push`	写入	提交当前变更，发起 MR/PR
`teamai push --all`	写入	提交全部文件变更
`teamai pull`	读取	同步远端最新配置到本地
`teamai pull --dry-run`	读取	预演同步结果，不实际改动
`teamai status`	检查	本地与远端差异一览
`teamai list`	检查	已安装技能清单
`teamai members`	检查	成员管理视图
`teamai skill show <技能名>`	检查	查看技能描述与内容
`teamai skill exclude add <技能名>`	检查	个人排除某技能，不再同步
`teamai skill exclude remove <技能名>`	检查	取消个人排除

排查问题时还会用到两条通用 Git 命令：git log --oneline 翻变更历史（谁的哪次提交改了什么），git revert <commit> 撤销一次已合并的问题变更——配置仓库就是 Git 仓库，代码世界的排查手段全部适用。

常见问题 FAQ

Q：push 之后，其他成员多久能用到新配置？ 合并进远端仓库的那一刻，配置在团队层面生效；成员本地的生效时间取决于同步方式——手动 pull 立即生效，配了 SessionStart Hook 则下次会话启动自动生效。「别人怎么还没拿到」的排查顺序：先确认 MR/PR 是否已合并，再让对方跑 teamai status 看本地与远端的差异。

Q：push 会直接改远端仓库吗？ 不会。push 发起的是变更请求，GitHub 走 PR、TGit/CNB 走 MR，管理员审核合并后才真正进仓库。这也是默认普通成员只读的原因——写权限集中在少数人手里，变更可审可控。

Q：dry-run 显示会删除我本地的某个文件，正常吗？ 说明远端有人删除或重命名了共享 Skills，本地这份即将被清掉。先和提交者确认一下，没问题再正式 pull；如果这个技能只是不适合你个人，用 teamai skill exclude add 加进排除清单，不必动团队配置。

Q：怎么判断自己是不是在用旧配置？ teamai status 是权威答案：本地与远端有没有差异、差在哪些文件，一眼看清。如果你经常忘了查，说明该配 SessionStart Hook 了——把「记得检查」从人脑移交给机制。

Q：push 被拒绝了怎么办？ 先分清两种拒绝：Git 层面的冲突（先 pull 解决冲突再 push）和权限层面的拒绝（只读成员没有 push 权限）。前者靠小步提交最大程度避免，后者找仓库管理员在托管平台侧申请写权限。

变更冲突怎么办

和所有 Git 工作流一样，本地改动与远端变更冲突时，Git 会拦下来要求先解决冲突。实操建议：小步提交——一次 push 只带一个逻辑变更（一个 Skill 或一组相关 Rules），冲突概率和解决成本都最小。大杂烩式的「攒一个月一起 push」，冲突解决起来是灾难。

push/pull 的机械动作就这么多，真正的价值在流转的内容上——Skills 和 Rules 怎么组织、怎么治理，见下一篇文章。