Tencent/teamai-cli: a Git-backed CLI for sharing AI agent skills across a team

The problem teamai-cli addresses: AI setup that lives on one laptop

Every engineer on a team configures their AI tool separately. One person has a review skill that catches migration mistakes, another has a rule file that forbids a deprecated internal API, a third has an MCP server wired up for the ticketing system. None of it travels. The README frames the problem as turning "individual AI capabilities into shared team capabilities, across agents, machines, and team members." That is the whole pitch, and it is a real gap: agent configuration is usually per-machine state, not a repository artifact.

The project targets teams rather than solo users, though the README lists "Team admin / solo user" as one role. The unit of sharing is a Git repository you control. A team admin creates it, grants write access to members, and runs teamai init against the URL. Members run the same command and get the team's skills, rules, docs, env, agents, hooks and MCP configuration installed into their tool of choice. Team Context (recall, learnings, codebase graph, teamwiki) and Team Improvement (usage, sessions, dashboard) are labelled beta in the architecture table, so the stable surface today is Team Execution.

How the sync works: Git as the transport, a skill as the entry point

The mechanism is deliberately unglamorous. TeamAI does not run a server you have to host. The shared-experience repo is the source of truth, and the CLI pulls from it. The README states that once initialized, "every AI session automatically pulls the latest skills / rules and other Harness updates published by admins, no manual sync needed." The commands behind that are init, pull and push. The package depends on simple-git, which is consistent with a Git-backed design rather than a bespoke protocol.

The second mechanism is the skill interface. Rather than requiring every user to learn flags, TeamAI ships a skill at skills/teamai inside the repository. You paste a single line into your AI tool telling it to install that skill and set TeamAI up from scratch. After that, you talk to /teamai in natural language: set up a team, join a team by repo URL, share a skill with the team, open the dashboard. The CLI exists underneath; the skill is the documented front door.

The compatibility matrix is the part worth reading closely. Claude Code, Codex, Cursor, CodeBuddy and WorkBuddy cover the full set of Team Execution resources in the table. GitHub Copilot CLI covers skills through mcp but shows a dash for usage, sessions and dashboard. OpenCode's row is truncated in the README, so its full coverage cannot be confirmed from what is published. If you standardize on Copilot CLI, expect Team Execution only.

Installing teamai-cli and initializing your first shared repo

The README offers two paths. The Quick Start path is the skill: send one line to your AI tool and let it install and configure everything. The manual path is the CLI, documented under a collapsible "Prefer the command line?" section.

The global install pulls the package from npm and puts a teamai binary on your PATH, since package.json declares bin.teamai as dist/index.js. The package is published with publishConfig.access set to public.

npm install -g teamai-cli

Before running init, the README requires a shared-experience repo on your git host with write access granted to team members. It names GitHub, GitLab, GitCode, CNB, TGit and private Git services as options. If you have no repo yet, the README points at the teamai-hub organization: fork a template pre-loaded with skills, rules and review agents, then init against your fork.

For a team admin or solo user, init takes the repository URL:

teamai init https://github.com/yourorg/yourrepo

For a team member, the README shows two scopes. Project scope is the default and installs resources under the project directory; user scope installs them under your home directory. Pick based on whether the configuration should follow the repository or the machine.

cd /path/to/my-project
teamai init https://github.com/yourorg/yourrepo

# or, user-scope
teamai init https://github.com/yourorg/yourrepo --scope user

After init, the README says sessions pull the latest published updates automatically. The README does not document a rollback path if a pull brings in a rule or hook that breaks your workflow, and it does not describe how conflicts between a local edit and an admin's push are resolved. That is the first thing to test on a throwaway repo.

Where teamai-cli stops being the right tool

The auto-pull behaviour is the sharpest limitation. If every session pulls the latest Harness updates, then an admin's push reaches every teammate's next session without a review step. For a rule that says "never touch the billing module without a second reviewer," that is fine. For a hook that runs a command, or an env file, it means a single push changes what executes on dozens of machines. The README describes the sync as automatic and does not describe an approval gate, a staged channel or a pin-to-version option.

Second, the tool assumes a Git remote that every participant can reach and that at least one person can write to. Teams behind an air-gapped network, or teams whose git host is not one of the named services, need a private Git service the CLI can clone from. Nothing in the README suggests an offline mode.

Third, the beta labels matter. Team Context and Team Improvement are marked beta in the architecture table, and the most recent releases are v0.25.0-beta.3, v0.25.0-beta.2 and v0.25.0-beta.1, all published in mid-September 2026. The npm package's own version field in the repository reads 0.22.0, which is a version behind the release tags. If you need the dashboard, sessions or learnings features to be stable, this is not yet that tool.

Finally, multi-agent coverage is uneven rather than universal. WorkBuddy shows a dash for agents in the table. Copilot CLI shows dashes for the entire Team Improvement column. A team that mixes tools will get a different resource set depending on who is running what.

teamai-cli compared with committing agent config directly to each project

The obvious alternative is to check .cursor/rules, CLAUDE.md, AGENTS.md and similar files into each project repository and let normal code review govern them. That approach has real advantages: changes go through pull requests, history is per-project, and there is no extra binary in the loop. The repository itself uses AGENTS.md and CLAUDE.md at the top level, so the maintainers are not allergic to the pattern.

The difference is scope and lifecycle. Project-committed config is per-repository and per-tool; a skill written for one service does not follow you to the next. TeamAI centralizes the definitions in one shared-experience repo and distributes them to whichever agent you run, with init, pull and push as the sync primitives. It also covers surfaces that plain config files do not: hooks, MCP server definitions, env, and the beta layers for learnings and sessions.

The trade-off is a second source of truth. With project-committed config, the repository and the configuration cannot drift. With TeamAI, the shared-experience repo and the project repo can disagree, and the README does not describe precedence rules for that case. If your team's agent configuration is small and stable, committing it per project is simpler. If you have many repositories, several agent tools, and a growing library of skills you want reused, the central repo earns its keep.

Maintenance, licensing and what to pin

The repository is not archived, and the last push was on 2026-09-20, three days before this writing, with beta releases on 2026-09-16, 2026-09-17 and 2026-09-18. The project is moving quickly on a beta line. That cuts both ways: fixes arrive fast, and so does churn in a tool that writes configuration into your home directory or project directory.

On licensing, the signals conflict. The README carries a badge reading "License: MIT" and links to a LICENSE file, and package.json declares "license": "MIT". The repository metadata reports NOASSERTION, which usually means the platform could not match the file to a known template. Read the LICENSE file itself before you depend on it, and note that the README does not discuss what happens to team content stored in a shared-experience repo, nor whether the CLI sends anything to a hosted service. Nothing published describes telemetry, so treat that as undocumented rather than absent.

For upgrade cost: the CLI is a global npm install, so version pinning is on you. The README does not document a compatibility guarantee between CLI versions and the skill or the shared repo layout. Pin the version your team validates, and re-run teamai init --scope user on a test machine before bumping everyone.

Editorial conclusion

Adopt teamai-cli if your team already runs Claude Code, Codex, Cursor, CodeBuddy or another supported agent and you want one Git repository, not a wiki page, to define the skills, rules, hooks and MCP servers every session starts from. Skip it if you have a single agent setup, no shared Git remote your teammates can write to, or no appetite for a 0.25.0 beta line where Team Context and Team Improvement are still marked beta. Before rolling it out, verify three things: that your git host is reachable from every machine that will run teamai init, that the CLI version you pin is the one your team tests against, and that the repository's LICENSE file, not the npm metadata, states the terms you are prepared to accept.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Tencent/teamai-cli on GitHub