【2026 最新】TeamAI CLI 教學：7 步共用 Skills、Rules 與 MCP

同一條「不要把密鑰寫進輸出」規則，在 Claude Code 有效、到了 Codex 只看到檔案卻不能證明已載入、進 Cursor 又變成另一種檔案——真正危險的不是少複製一份設定，而是團隊誤以為三個 Agent 的語意相同。這篇 TeamAI CLI 教學會用一個拋棄式 repo，帶你同步一個 Skill、一條 Rule 與一個假 MCP，再用故障注入檢查衝突、密鑰、Hook、Session 摘要與回滾。

本文固定在 2026 年 9 月 11 日的穩定版 TeamAI CLI v0.23.1。AlphaLab 在隔離的 /tmp fixture 安裝該版本、確認版本號，並重跑 Skills、Rules、MCP、Hooks、Session 與轉譯相關的 204 個測試；它們全部通過，但這只證明受測程式路徑符合專案測試，不等於三個產品已做到完全互通。

你會得到的不是「一鍵魔法」，而是一套可以審查的上線標準：檔案有生成、Client 有載入、敏感資料沒外流、共享來源可回復、受管產物可清理。如果你還不熟悉 Model 與 Harness 的差別，可先看 AI Agent Harness 是什麼；本文直接處理多人治理。

先說結論：TeamAI 值得用，但同步不等於相容

TeamAI 的核心公式是：Git 單一來源＋各 Agent 轉譯器＋Pull／Review 閘門。

• 它解決的是分發與治理：團隊把 Skills、Rules、MCP 等資源放進 Git，透過 push／PR 與 pull 分送，而不是三個人各自維護三份副本。
• 它不替三個 Client 定義同一種語意：Claude Code、Codex、Cursor 對 instruction、rule、skill、MCP 與 Hook 的原生位置和格式仍不同。
• 最小安全做法：先在私有測試 repo 固定版本，關閉團隊自訂 Hook 與 MCP 的自動套用，讓每個 Client 跑同一個 canary；全部通過才導入正式 repo。

因此，TeamAI 比較像「編譯器＋套件配送站」，不是「跨 Agent 的共同作業系統」。原始碼是你的 Git repo；Claude、Codex、Cursor 的設定是各自的 build artifact。這個心智模型也能接上 AI Agent Harness 實作教學：共享資源只是 Harness 的一層，執行權限與 runtime control 仍要分開管。

TeamAI CLI 是什麼？先看懂「一份來源、三個產物」

TeamAI CLI 是 Tencent 開源的命令列工具。官方 v0.23.1 指南把團隊資源放在共享 Git repo，再依工具輸出到 Claude Code、Codex、Cursor 等本機設定位置；teamai push 嘗試建立分支與 PR／MR，teamai pull 則把本機可見的 team source 轉成各 Client 格式。獨立 team-repo mode 會先更新本機 clone，self mode 則讀目前 checkout 裡的 .teamai；PR／merge 是本文加上的治理閘門，不是 Pull 的技術強制條件。這是供應商描述的支援矩陣，不是獨立互通認證。

差異首先出現在「Rules」這個字。Claude Code 的 .claude/rules/*.md與 Cursor 的 .cursor/rules/*.mdc都是提示脈絡；目前 Codex 官方文件的 .codex/rules/*.rules則是實驗性的指令執行政策。三者同名，不代表同一種能力。

Skills 也有邊界：Claude Code 原生路徑是 .claude/skills；Codex 官方文件使用 .agents/skills；Cursor 同時文件化 .agents/skills、.cursor/skills及若干相容路徑。TeamAI v0.23.1 預設把新的 Codex skill 寫到 .codex/skills，但若同名 skill 已存在於 .agents/skills，會改在那裡更新。這就是本教學一定要用 canary、不能只看檔案樹的原因。

開始 TeamAI CLI 教學前：準備一個可丟棄的測試 repo

官方穩定版指南要求 Node.js 20 以上與 Git。先固定版本，不要讓 latest 在不同成員電腦漂移：

node --version
git --version
npm install -g teamai-cli@0.23.1
teamai --version   # 預期：0.23.1

接著在 GitHub／GitLab 建一個私有、無正式密鑰、可整個刪除的 repo，建立時先加入 README，確保遠端已有預設分支與至少一個 base commit。這不是唯讀實驗：除了 Git clone 權限，teamai init .還需要 Git provider 的 API 驗證與遠端寫入權限；GitHub 可先確認 gh auth status，GitLab 則依官方流程完成 API token 驗證，不要把 token 寫進 repo 或 shell history。初始化期間，它除了建立 .teamai與各工具設定、提交目前分支，還會嘗試把成員註冊寫到遠端 teamai-reports分支。只在你獲准寫入的測試 remote 操作；依據是 single-repo mode 指南與初始化流程。

git clone git@github.com:your-org/teamai-lab.git
cd teamai-lab
git switch -c chore/teamai-pilot
git config user.name
git config user.email

teamai init . --agent claude,codex,cursor
teamai status
git status --short

如果你要讓一套團隊知識跨多個產品 repo 使用，官方另有獨立 team repo 模式；本文先用 single-repo mode，把所有產物限制在一個實驗場。初始化後先檢查新增的 .claude、.codex、.cursor 與 .teamai。此刻先不要推送初始化 commit；下一步會先加安全預設與 owner，再把完整 baseline 送進 setup PR。

TeamAI CLI 教學：7 步建立可審查的共享設定

第 1 步：先隔離團隊自訂 Hook 與 MCP

痛點：Pull 之後，團隊自訂 Hook 可能在對應事件觸發時執行；若 MCP 設定已寫入原生 config，Client 載入並呼叫它時也會取得執行能力。reviewer 還沒看懂前，不該讓它們進入這個狀態。解法：只把現有 .teamai/teamai.yaml的 sharing區塊替換成以下「完整合併後」版本，保留 team、mode、repo、provider等其他頂層欄位；不要在同層再貼第二個 sharing:：

sharing:
  rules:
    enforced: []
  docs:
    localDir: ./.teamai/docs
  env:
    injectShellProfile: true
  hooks:
    autoApply: false
    requireTeamScripts: true
  mcp:
    autoApply: false
    allowedHosts:
      - example.com

這裡要分開看：Hooks 設成 autoApply: false 後，可再由人執行 teamai hooks inject；但它只擋團隊自訂 Hook，teamai init 安裝的 SessionStart pull、session／telemetry handler 等 TeamAI 內建操作 Hook 仍會保留。若測試目標是完全不執行 TeamAI 受管 Hook，應在拋棄式 lab 執行 teamai hooks remove，並接受自動 Pull 也一起失效；這不會移除其他使用者自行設定、非 TeamAI 管理的 Hook。另一方面，v0.23.1 的 MCP 實作在 autoApply: false 時，連明確呼叫 teamai mcp inject也會提前返回。因此它在本版是「隔離開關」，不是完整的人工批准流程。審查通過後，應在另一個受審 PR 把 MCP 的值改成 true，先於測試 repo 套用，再考慮正式環境。requireTeamScripts與allowedHosts是額外護欄，不是 sandbox；真正權限仍由各 Client 與 OS 決定。需要更完整的執行層設計，可接著看 Agent Runtime Controls。

在 setup PR 合併前就設 owner；否則第一批資源 PR 仍可能沒有強制 reviewer。以下是 GitHub .github/CODEOWNERS 的最小示意，請把 team 名稱換成實際群組，並在遠端 branch protection 開啟「Require review from Code Owners」：

.teamai/skills/       @your-org/agent-owners
.teamai/rules/        @your-org/agent-owners @your-org/product-owners
.teamai/mcp/          @your-org/agent-owners @your-org/security
.teamai/hooks/        @your-org/agent-owners @your-org/security
.teamai/team-scripts/ @your-org/security
.teamai/teamai.yaml   @your-org/agent-owners @your-org/security
.github/CODEOWNERS    @your-org/security
.claude/settings.json @your-org/security
.codex/hooks.json     @your-org/security
.cursor/hooks.json    @your-org/security

同一個 setup PR 還要先把 v0.23.1 會寫入的兩個 project MCP 產物放進 repo 根目錄 .gitignore。若既有 repo 已經追蹤它們，新增 ignore 規則不會自動取消追蹤；下列第一個檢查必須沒有輸出，第二個則必須顯示命中的 ignore 規則：

# .gitignore（repo root）
/.mcp.json
/.cursor/mcp.json

git ls-files -- .mcp.json .cursor/mcp.json
git check-ignore -v --no-index .mcp.json .cursor/mcp.json

teamai init .對 setup knowledge 只嘗試建立本機 commit，不會替你把它合併到預設分支；前述 member registration 則是另一條 reports 資料流。初始化的 Git commit 是 best-effort，因此先確認剛才的 user.name／user.email都有值，再用精確 subject 判斷是否能 amend；如果 init commit 不存在，另建 setup commit，絕不能盲目 amend 到原本的 README base。修改 YAML 後也要重跑 teamai status驗證能解析。等 setup PR 合併後，回到最新預設分支再開本機驗收分支。這個順序很重要，因為 single-repo 的 teamai push會從 origin/<default-branch>建立隔離 worktree：

teamai status
if [ "$(git log -1 --pretty=%s)" = \
  "[teamai] Initialize single-repo mode (skills/rules/docs/learnings skeleton)" ]; then
  git add .teamai/teamai.yaml .github/CODEOWNERS .gitignore
  git commit --amend --no-edit
else
  git add .teamai .claude .codex .cursor .github/CODEOWNERS .gitignore
  git commit -m "chore(teamai): initialize guarded pilot"
fi
git show --stat --oneline HEAD
git push -u origin chore/teamai-pilot
# 在遠端 review 並合併 setup PR 後：
git switch <default-branch>
git pull --ff-only
git switch -c pilot/teamai-canary

第 2 步：只放一個 Skill、一條 Rule、一個假 MCP

痛點：一次同步 30 個資源，失敗時無法判斷是格式、路徑還是內容。解法：先建立以下最小樹狀結構：

.teamai/
├── skills/teamai-canary/SKILL.md
├── rules/teamai-canary.md
└── mcp/mcp.yaml

SKILL.md 明確放入 Codex 與 Cursor 需要的 name／description，並設計一個不執行工具的驗收語句：

---
name: teamai-canary
description: Respond to the TEAMAI_CANARY test without using tools.
---

# TeamAI canary
When the user says TEAMAI_CANARY, reply exactly: TEAMAI_OK
Do not run commands, read files, or use network tools.

rules/teamai-canary.md 只做另一個可觀察回應：

# TeamAI rule canary
When a prompt contains TEAMAI_RULE_CANARY,
begin the reply with RULE_OK.

最後在 mcp/mcp.yaml 放一個不承載真實資料的 HTTP canary。它只用來檢查轉譯結果，本文不會呼叫該 endpoint：

servers:
  - name: teamai-canary
    transport: http
    url: https://example.com/api/mcp
    headers:
      Authorization: Bearer ${TEAMAI_CANARY_TOKEN}
    tools: [claude, codex, cursor]

測試值可設成明確的假字串，例如 TEAMAI_CANARY_TOKEN=not-a-secret。不要拿真實 token 做 canary。

第 3 步：把 dry-run 當「目標預覽」，不要當零寫入保證

痛點：v0.23.1 的 CLI help 把 --dry-run描述成 preview，但實際邊界比字面窄。解法：只在測試 repo 執行，並把 Git 狀態一起記錄：

git status --short
teamai pull --dry-run
git status --short
git diff -- .teamai .claude .codex .cursor .agents

另外一個獨立 team-repo mode 的隔離 fixture 裡，AlphaLab 讓本機 clone 落後上游一個 commit：pull --dry-run 沒把 Rule 寫進目標 Agent 目錄，但該 team-repo clone HEAD 仍前進到新 commit。這不是上面 single-repo lab 的同一路徑；v0.23.1 的 pull 分支對 self mode 不會 Git pull 或 flush pending learning，但仍可能遷移舊的 .teamai/.gitignore；獨立 Git team repo 才會先 pull 並處理 pending learning。結論仍相同：--dry-run只能當目標資源部署預覽，不能跨 mode 推論成唯讀 transaction。

第 4 步：正式 Pull 後，逐一驗證路徑與語意

痛點：檔案存在最容易製造假成功。解法：先備份或提交乾淨基準，再執行 Pull，列出產物，最後分別開三個 Client 跑 canary：

teamai pull --force
teamai mcp list
teamai hooks list

find .claude .codex .cursor .agents -type f 2>/dev/null | sort

• 先避免 implicit invocation 的假陰性：在 Claude Code 明確輸入 /teamai-canary TEAMAI_CANARY，Codex 輸入 $teamai-canary TEAMAI_CANARY，Cursor 輸入 /teamai-canary TEAMAI_CANARY；預期回覆精確等於 TEAMAI_OK。如果命令根本未列出，記成 Skill 發現／路徑失敗，不要怪模型沒自動觸發。
• Rule 另行輸入 TEAMAI_RULE_CANARY，確認回覆是否以 RULE_OK 開頭。
• MCP 此時仍在隔離狀態；用 teamai mcp list檢查定義與 secret 狀態，不應把 native config 中尚未出現 server 當成失敗。

若 Codex 的 Rule canary 沒觸發，不要把檔案複製成功誤判成產品故障。TeamAI v0.23.1 會把 Markdown 寫進 .codex/rules，而目前 Codex 官方文件把該目錄定義成 .rules command policy，主要 instruction 則走 AGENTS.md。若 Skill 也沒載入，檢查是否落在官方的 .agents/skills。在上游對齊前，將這兩項列為 release blocker，不要用「大概有讀到」放行。

MCP 也要分產品看：Claude Code 使用 project .mcp.json，Cursor 使用 .cursor/mcp.json，Codex 使用 TOML。TeamAI v0.23.1 的 Codex adapter 只有 user-scope .codex/config.toml 目標；但目前 Codex 官方 MCP 文件本身已文件化可信專案的 .codex/config.toml。所以這是 TeamAI adapter 的版本邊界，不是 Codex 產品本身的限制。

第 5 步：把 Push、PR 與 CODEOWNERS 接起來

痛點：Git 有歷史，不代表有人審查。解法：Skills／Rules 的變更用 teamai push 掃描；v0.23.1 的 push 流程會從已合併的預設分支建立隔離 worktree、推送資源分支，並嘗試向支援且已驗證的 Git provider 開 PR／MR；若 API 建立失敗則保留分支，由人手動開 PR。MCP 在 single-repo mode 不走 teamai push，要用一般 Git PR。setup PR 已放入 CODEOWNERS；現在分別送出資源 PR 與只含 MCP source 的 PR：

# Skills / Rules：互動清單只選兩個 canary
teamai push

# MCP source：在目前 pilot 分支走一般 Git review
git add .teamai/mcp/mcp.yaml
git commit -m "chore(teamai): add reviewed MCP canary"
git push -u origin pilot/teamai-canary

確認資源 PR（可能不只一個）與 MCP-source PR 都經 CODEOWNERS 審查，並且只合併到這個可刪除的 lab，用來完成後續故障注入；任何 Client blocker 都不得 promotion 到正式 repo。分支保護與遠端 CI 才是硬閘門，因為 TeamAI 管理的知識 commit 會略過本機 Git hook。不要直接在仍帶本機產物的 pilot checkout 繼續；另做一份乾淨 clone，確認所有 PR 都已進入 lab 的預設分支。下一個 teamai status在缺少本機 config 時會刻意觸發 self-bootstrap，可能寫入本機 config／state、注入 Hook，並再次嘗試 reports member write；它不是唯讀 cleanliness check。只在同一個已授權 lab 執行，完成後再檢查 Git 工作樹，才開 MCP-enable PR：

cd ..
git clone git@github.com:your-org/teamai-lab.git teamai-lab-enable
cd teamai-lab-enable
teamai status
git status --short
git switch -c feat/teamai-mcp-enable
# 只把 sharing.mcp.autoApply 改成 true
git add .teamai/teamai.yaml
git commit -m "chore(teamai): enable reviewed MCP canary"
git push -u origin HEAD

MCP-enable PR 合併後，切回含該變更的預設分支，才用假值執行 injection。這個 project-scope fixture 預期只出現 Claude 的 .mcp.json與 Cursor 的 .cursor/mcp.json；v0.23.1 沒有 Codex project MCP target，因此 Codex 被跳過才是預期結果，不可把三種 native config 都出現寫成通過條件。fixture 只有一個受管 server；測完先移除它，再依第 7 步回復 enable change：

git switch <default-branch>
git pull --ff-only
export TEAMAI_CANARY_TOKEN='not-a-secret'
teamai mcp inject
teamai mcp list
git check-ignore -v --no-index .mcp.json .cursor/mcp.json
teamai mcp remove
git status --short

第 6 步：做四種故障注入，不要等正式事故

痛點：正常路徑通過，只能證明 happy path。解法：在拋棄式分支逐一製造以下情境，每次只改一項：

1. 同名衝突：先在其中一個 Agent 的 rules 目錄放同名但不同內容的本機檔，再 Pull。v0.23.1 原始碼顯示，同名團隊 Rule 會覆寫，且當團隊至少有一條 Rule 時，部分 Agent rules 目錄中不在團隊集合的檔案可能被當成 stale 而移除。正式環境前一定要備份並檢查 清理邏輯。
2. 密鑰誤入：來源只放 ${VAR}，但 v0.23.1 MCP 指南說明，它會解析後把值寫進各 Client 的原生設定；新建檔案權限設為 0600，專案設定仍必須 gitignore。用假 canary 同時檢查 git status --short、git diff、git diff --cached、每個產物的 git check-ignore，再跑會涵蓋 untracked files 的 secret scanner。TeamAI 是轉譯器，不是 secret vault；可搭配 AI Agent 密鑰安全教學建立輪替與撤銷流程。
3. Hook 失效：本 fixture 刻意沒有加入 team/custom Hook，因此不宣稱驗證了 TEAMAI_HOOKS_DISABLED=1；等日後加入無害的自訂 marker Hook 時，可把它當 kill-switch 測試模板，但要記得它不會停用 TeamAI 內建 Hook。本文現在能實際驗收的是自動 Pull 失效：在拋棄式 fixture 執行 teamai hooks remove，或刻意不完成 Codex Hook trust，再啟動新 session，確認 SessionStart 沒有自動 Pull，最後驗證手動 teamai pull仍能恢復同步。手動 Pull 只是自動 Pull 的 fallback，不是 deny Hook 失效時的安全替代品。依 Codex Hook 文件，新增或變更 Hook 後還要在 /hooks或 Settings 完成 review／trust，檔案生成不代表 Hook 已執行。TeamAI v0.23.1 的 Cursor event map也未列入 PreToolUse，即使目前 Cursor 官方 Hook已支援該事件，也不能把共享 deny Hook 當成三方等價的強制控制。
4. Session 摘要外洩：只執行本機 teamai session save仍不代表資料只在摘要檔。先檢查 ~/.teamai/session-logs；若事件裡有 prompt，本機摘要預設就會包含經 best-effort 脫敏的首段 prompt，v0.23.1 的 摘要格式也包含 project path，完整 session ID 則存在檔案註解。還要檢查 ~/.teamai/dashboard/events.jsonl：dashboard collector 會先把 prompt 開頭最多 200 個字元寫進本機事件檔，debug log 也可能出現前 60 個字元，這條本機資料流不受 session summary 脫敏保護。對被判定為 valuable、或另加 --force的 session，--push會直接寫入 reports commit；否則可能跳過。只有推送到 team reports 的版本，才由 --include-prompt決定是否帶上經 best-effort 脫敏的首段 prompt。未完成資料分類與本機留存政策前，不要使用這些 push 旗標，也不要把不 push 誤當成沒有 prompt 留存。

第 7 步：回復共享來源，再清理受管產物

痛點：只刪本機產物，下次 Pull 又可能把壞設定裝回來；只 revert Git，也救不回先前被覆寫、卻未備份的個人 Rule。解法：先在第一次 Pull 前保存個人設定；事故時先檢查目標 commit 的 parent 與 diff，回復共享來源的變更，讓 revert 也經過 PR，再移除受管 MCP／Hook 產物並重新 Pull：

git switch <default-branch>
git pull --ff-only
git switch -c revert/teamai-canary
# 若 PR 是 squash／rebase 後的普通 commit
git revert <change-commit>
# 若目標真的是 merge commit，改用：git revert -m 1 <merge-commit>
git push -u origin HEAD

# revert PR 合併後，每位成員切回含有該 revert 的分支並更新
git switch <default-branch>
git pull --ff-only
teamai mcp remove       # 僅在 MCP 事故時
teamai hooks remove     # 僅在 Hook 事故時
teamai pull --force

這是來源 rollback＋受管產物重建，不是完整 transaction：個人檔案只能從你事前保存的 backup 還原；MCP／Hook remove 也應按事故類型選用，避免清掉無關的受管項目。版本資料目錄遷移另有 .teamai.bak 人工回復路徑。先保留失敗現場與 diff，再動手清理。若你要比較 Claude Code 與 Codex 的其他執行差異，可接著讀 Claude Code vs Codex 客觀比較。

到底哪些設定能共用？用「可攜性」而不是檔名判斷

• 最適合共用：純 Markdown 程序、檢查清單、輸出格式、沒有工具副作用的 Skill。採三方都能接受的 name與description frontmatter，再跑 canary。
• 可以轉譯，但要驗收：Claude／Cursor 的 prompt Rules、MCP server 宣告、部分 lifecycle Hook。檔案格式和信任機制不同，不能只比內容 hash。
• 應分工具維護：Codex command policy、Client-specific permission、Hook 事件與 fail-open／fail-closed 行為、遠端或 cloud 執行環境。
• 只分享文件，不分享執行能力：當團隊還沒有 CODEOWNERS、branch protection、secret scanning 或回滾演練時，先同步 docs／Skills 的文字知識，暫緩 Hooks 與帶 credential 的 MCP。

簡單判斷：如果資源只是「教 Agent 怎麼想」，可攜性通常較高；如果資源能「讓 Agent 執行命令、連線或取得權限」，就必須在每個 Client 重新做 threat model。MCP 的 Tool Description 與 schema 也可能改變 Agent 行為，進階審查可參考 MCP Tool Description Injection 六步審計。

TeamAI CLI 的誠實限制：目前最該盯的 5 個坑

1. Dry-run 邊界比名稱窄：它能跳過目標資源部署，但 v0.23.1 仍可能更新內部 team-repo clone與處理 pending learning。
2. Pull 不是三方 merge：同名資源以團隊來源為準，Rules 還有 stale-file cleanup；先備份本機個人規則。
3. Codex adapter 有文件落差：Skills、Rules 與 project MCP 都要對照目前 Codex 官方路徑，不要只信 TeamAI 產物位置。
4. Hook 信任與事件不等價：Codex 要額外 trust；Cursor 的 Claude Hook 相容層只涵蓋文件化子集，且執行環境仍可能不同。
5. Session metadata 也可能敏感：即使推到 team reports 的版本預設不帶 prompt，專案路徑、session identifier、工具名稱與使用模式仍可透露組織資訊；本機摘要與 events 檔另有 prompt 留存。

截至 2026 年 9 月 11 日，npm 穩定版是 0.23.1，另有 0.24.0-beta.5 beta；官方 main README 也把 Team Context 與 Team Improvement 標為 beta。本文因此不把 recall、session learning 或自動改善效果寫成承諾。升版時重跑同一組 canary、故障注入與 200+ targeted tests，比閱讀行銷式 support matrix 更有價值。

TeamAI CLI 適合你嗎？三種決策

• 選 TeamAI：團隊同時使用多個 coding agent、有 Git review 文化，也願意為每個 Client 維護驗收測試。
• 先用簡單 Git／symlink：只有一兩位開發者、資源幾乎全是純文字 Skills，而且你能明確掌握各工具原生路徑。Symlink 支援也要逐工具依官方文件確認。
• 暫時只共享文件：組織尚未建立秘密管理、branch protection、owner 與事故回復程序。先把知識共用，再逐步開放執行能力。

這三個選項不是互斥。你可以先以 Git 管理 canonical Markdown，再讓 TeamAI 只承擔已通過 canary 的資源；高風險 Hooks 與 MCP 維持 client-specific。真正的成熟度不是「同步比例 100%」，而是每一條自動化能力都有 owner、證據與撤回路徑。

TeamAI CLI 教學 FAQ

1. TeamAI 能讓 Claude Code、Codex、Cursor 完全共用同一份設定嗎？

不能把「完全共用」當驗收前提。TeamAI 能共享 canonical source 並轉譯，但三個 Client 的 instruction、Rules、MCP、Hooks 與信任模型不同。每種資源都要跑 client-specific canary。

2. TeamAI CLI 免費嗎？

v0.23.1 repo 以 MIT License 開源。Git host、企業治理、各 AI Client、模型或 MCP 服務本身可能另有成本；本文只討論 CLI 與設定工作流。

3. 可以直接在正式 repo 執行 teamai init 嗎？

第一次不要。init會建立設定並提交目前分支；先在私有測試 repo 看清楚產物、Hook 與 MCP，再用受保護 PR 導入正式專案。

4. teamai pull –dry-run 會完全不寫入嗎？

在 v0.23.1，不應把它視為零寫入保證。我們在獨立 team-repo mode 的隔離重現中看到目標 Rule 沒部署，但內部 team-repo clone 仍更新；原始碼也把該 mode 的 refresh 與 pending-learning flush 放在部署判斷前。single-repo self mode 走的是另一條路徑。

5. MCP 的 ${VAR} 會一直保持變數嗎？

已定義的變數不會保持佔位符。TeamAI v0.23.1 會解析它，再把值寫進各工具原生設定；缺少的變數則跳過、不會把 ${VAR}原樣寫入。共享 source 不放明文只是第一層；產物仍要 gitignore、限權、掃描與輪替。

6. 為什麼 Codex 沒讀到 TeamAI 的 Rule？

先查語意與路徑，不要只重跑 Pull。目前 Codex 把 AGENTS.md當 instruction，把 .codex/rules/*.rules當 command policy；TeamAI v0.23.1 輸出的 Markdown Rule 並不等於這兩者。

7. 所有 TeamAI 變更都會經過 PR 嗎？

不是所有資料流都一樣。Skills／Rules 的 teamai push會建立分支，並只在支援且已驗證的 Git provider 嘗試開 PR／MR；失敗或一般 Git remote 要由人手動開 PR。single-repo 的 MCP／Hooks／docs 要由一般 Git PR 管；初始化的 member registration 會寫 reports 資料流，而被判定 valuable（或加 --force）的 session save --push也會直接寫 reports commit，因此必須另設存取政策。

8. 發現壞設定時，共享來源應怎麼回復？

先 revert canonical Git change，再按類型清理受管產物並 Pull。把 revert 本身也當 PR；個人 Rule 等非受管資料要靠事前 backup 還原，因此這不是全機器的交易式 rollback。

給新手的 5 個重點

1. 固定 TeamAI 版本，第一次只在可丟棄的私有 repo 操作。
2. 把 TeamAI 視為 Git source 的轉譯與配送層，不是跨 Agent 語意保證。
3. 從一個 Skill、一條 Rule、一個假 MCP 開始，三個 Client 跑同一個 canary。
4. Hook、MCP、Session 都可能帶出執行能力或 metadata；預設人工批准。
5. 事故時要回復 Git 來源、清理受管產物；個人設定則從事前 backup 還原。

想繼續建立自己的 AI 工程能力，可回到 AlphaLab AI 專區看完整系列；需要有系統的實作路線，也可查看 AlphaLab 課程。