I run three coding agents depending on the task, and I have never once managed to keep their rule files identical. They start as copies of each other. One picks up a new convention, another gets edited on a bad afternoon, and a few weeks later there is no answer to the question of which version the team actually agreed on. The agent reading the stalest copy is the one that argues confidently for last quarter's conventions in a review. 😅
Tencent published a CLI called teamai-cli that stops treating this as a discipline problem and treats it as distribution.
What lives in the repo
One git repo holds the whole harness, and each resource has a fixed home:
| Resource | Path in the team repo |
|---|---|
| Skills | skills/<name>/SKILL.md |
| Rules | rules/*.md |
| Agents | agents/<name>.yaml |
| Hooks | hooks/hooks.yaml |
| MCP | mcp/mcp.yaml |
| Docs | docs/ |
| Culture | culture.md |
culture.md is the one I did not expect. It carries the team's mission, values and working principles, and it gets injected into each agent's CLAUDE.md or AGENTS.md, so every session inherits them without anybody pasting anything. docs/ is not all loaded by default, which the project calls progressive disclosure.
Setup
npm install -g teamai-cli
teamai init https://github.com/yourorg/yourrepo
Project scope is the default and installs the resources under the project directory. --scope user puts them under your home directory instead. The store can be GitHub, GitLab, GitCode, CNB, TGit or a git server you run yourself, so the repo can sit wherever your code already does.
The flow, which is the actual product
teamai push -> branch + MR -> reviewer approves and merges
|
v
SessionStart hook -> teamai pull -> local agent config
That is it. A change to a rule goes through the gate a change to code already goes through. Prompt configuration gets edited by everybody on a team and reviewed by nobody, and it has the widest blast radius in the tree, because a bad rule is wrong in every session on every machine at once.
Nobody has to take all of it
teamai roles maps a role to a namespace so a member syncs only the skills their role needs. teamai tags lets people subscribe to the pieces they want. teamai source subscribes to another group's skill repo on top of your own, which is how a shared internal library arrives without a fork. And learnings/ at the repo root is shared with everyone while learnings/<project-id>/ stays project-private, so one client's notes stay out of the general pool.
What I counted before installing it
What decides whether any of this arrives on your machine is which agents the project actually covers, so I counted: 11 agents against 13 capability columns. Skills and docs are filled on all 11. Hooks, MCP and rules come in at 8 each. Usage, sessions and dashboard come in at 7. 🧐
The split decides something, because the automatic delivery runs off a hook. The project says every session pulls the latest with no manual sync, and its own flow diagram routes that through SessionStart, while three rows (OpenClaw, Hermes and DeepSeek Harness) show a dash in the hooks column. The project draws no conclusion from that and I am the one drawing it, but on those three the pull is something a person remembers to run.
The caveat
It sits one table away from the good part. Look at the env/ row: it offers "Shared team-level environment variables and switches" and then tells you not to put secrets in it. So the settings that cost the most to keep aligned, the keys and the endpoints, are the ones the repo will not hold. You still need whatever you were already using for that.
The architecture table labels two of its three layers beta: the recall that searches accumulated team experience, and the usage reporting. The distribution layer above is the one that is not.
Repo: https://github.com/Tencent/teamai-cli
Which pieces of your agent config would you actually want a reviewer to gate, and which would that just slow down?
Top comments (0)