Tencent/teamai-cli

teamai-cli は、チームで使う AI エージェントの設定をまとめて配るコマンド。スキル、守らせたいルール、参照させたい文書、環境変数などを git リポジトリ1つに集め、そこから各自の手元へ配る。README の対応表に載っている配り先は Claude Code、Cursor、CodeBuddy など11種類で、同じ資産を別々のツールに届けられる。ただし何を受け取れるかはツールによって差があり、対応表には、ルールを受け取れないもの、フックや MCP の設定を受け取れないものが並んでいる。

配り方はシンプルだ。管理者がリポジトリを1つ用意して teamai init を走らせ、メンバーも自分のプロジェクトで同じコマンドを実行する。以後はAI のセッションが始まるたびに、最新のスキルとルールが自動で取り込まれる。手元のファイルを配り直したり、更新に気づかせたりする必要がない。追加や変更は、push してレビューを通してマージする、という普通のコードと同じ流れに乗る。役割やタグで、配る対象を絞ることもできる。

ベータとして、別の層が2つ付いている（README はどちらにもベータと付けている）。ひとつはうまくいかなかった場面を拾って、チームの記録に変える仕組みだ。AI を訂正した、ツールの実行を拒否した、といった「引っかかり」を各セッションで点数化し、値打ちのある問題は書き留めるよう促す。ここは促すところまでで、実際に書き留めるかどうかは人が決める。溜まった記録は、作業を始める前に teamai-recall という担当が検索して持ってくる。ただしこの引き当ては既定では止まっていて、明示的に有効にしないと動かない。引き当てるときは、取り込んだコードの依存関係の地図を使って検索結果の順位を付け直す（地図の作り方は2通りが同時に走る。構文解析が効くのは TypeScript・JavaScript・Python・Go で、全言語に効く粗い方法と重なったところは構文解析のほうを採る）。もうひとつは分析の層。週ごとの利用状況（成功、プロンプト、稼働時間、推定コスト、キャッシュ、訂正の傾向）をまとめたダイジェストがある。別に、進行中のセッションと手元の7日間の傾向を前の7日間と比べて見るダッシュボードも付いている。

人によって AI の出力の質がばらつくのを、そろえたいとき

コツを掴んだ人の書いた指示が、その人の手元で止まりがちになる。1か所に集めて自動で配る形にすると、入ったばかりの人にも、同じ指示が最初から入った状態にできる。

使っているエージェントが人によって違うとき

Claude Code の人と Cursor の人が混ざっていても、配る資産は共通のまま扱える。ツールを統一させずに、指示のほうを統一するやり方になる。ただし受け取れる範囲はツールごとに違うので、全員に確実に届けたいものは、対応表で確かめておく。

自動で取り込むということは、間違ったルールも同じ速さで広がりうる。 各自が意識して更新しないぶん、入った内容が、配られた相手のセッションにそのまま効く。push してレビューを通す運用を崩さないことが、そのまま安全装置になる。

利用状況の集計が入る。 週次のダイジェストは、成功、プロンプト、稼働時間、推定コスト、訂正の傾向をまとめる（その材料になるセッションごとの要約について、README が書いているのは「プロンプトや会話の本文は残さない」ということで、匿名になるという意味ではない。付属の使い方ガイドには、訂正の割合やトークン量が人ごとの順位として出ると書かれている）。誰の何を集めて誰が見るのかは、入れる前にメンバーに説明しておいたほうがいい。導入の判断と、働き方の記録が見られることへの納得は別の話になる。

引っかかりを拾う層と分析の層はベータ。 README がベータと付けているのはこの2つで、配布の部分には付いていない。ただし teamai init はセッション終了時のフックを入れる作りで、書き留めを促すヒントは設定で切れるものの、フックそのものは残る、と README は書いている。

引き当ては既定で止まっている。 記録を検索して持ってくる部分は、明示的に有効にしないと動かない。入れただけでは働かないので、使うつもりなら有効化まで手順に含める。

ライセンスは MIT。