MKMK 的 AI 筆記
MK 熱門 Skill 實測

第 7 篇／共 11 篇

tstack 實測：讓 AI 把 PR 一路跑到合併

閱讀約 8 分鐘（約 1,690 字）發布 分類 GitHub 飆星與 Skill 實測

#Claude Code#Skill#Codex#GitHub#Pull Request

tstack 實測：讓 AI 把 PR 一路跑到合併

tstack 是 Theo 公開的 9 個 Agent Skill，說一聲 full send，Claude Code 或 Codex 就會驗證、開 PR、找模型 review、盯 CI 到合併。我 clone 下來拆解相依關係與適合誰。

本文目錄
  1. 它是什麼
  2. 9 個 Skill 一覽
  3. 我實際拆開來看
  4. 寫法值得抄的 3 個地方
  5. 安裝
  6. 注意事項
  7. MK 觀點：適合誰、不適合誰
  8. 常見問題
  9. 延伸閱讀

我自己寫程式最煩的從來不是寫 code，而是後面那一串：開 PR、等 CI、回 review 意見、再等、最後按合併。tstack 就是把這整段寫成 Skill，說一聲「full send」，Claude Code 或 Codex 就一路幫你做到合併。我把它 clone 下來，9 份 SKILL.md 全部讀完，還畫了一張它們互相呼叫的關係圖，下面跟大家分享。

它是什麼

tstack 是 GitHub 帳號 t3dotgg 的 Theo Browne（LICENSE 上的署名）把自己每天在用的 Agent Skill 整理出來公開。README 寫得很直接：Claude Code 和 Codex 都能用。每個 Skill 其實就是一份 Markdown 說明書，你講出觸發詞，AI 就照著上面的步驟做。

tstack 的 GitHub 首頁，右側可以看到星數、授權與兩位貢獻者 圖：tstack 的 GitHub 首頁。來源：github.com/t3dotgg/tstack，2026-11-02 擷取。

  • 星數 2,592、Fork 170、MIT 授權、2026-10-24 建立（GitHub API，查證日期 2026-11-02）
  • 我讀的版本：commit 1085050（2026-10-27）

9 個 Skill 一覽

tstack README 的 Skill 表格，列出每個 Skill 的觸發詞與用途 圖：README 裡的 9 個 Skill 與觸發詞。來源：tstack 官方 README（授權 MIT）。

我最常會用到的大概是這幾個：

你說 它會做什麼
full send 從現在的修改一路做到 PR 合併，最後回報 PR 連結、合併 commit 和證據
full stop 跟上面一樣，但 PR 準備好就停，留給你自己按合併
council 找三家不同廠商的旗艦模型平行 review，各打 10 分制分數，修完再看，直到大家都滿意
babysit 盯著 CI 和 review 機器人，只修真正有問題的地方
take over 接手別人的 PR，保留原作者的 Git 署名和 co-author

我實際拆開來看

tstack 9 個 skill 的行數與互相呼叫關係 圖：我寫了一小段程式讀每份 SKILL.md，統計行數、找出內文提到哪些其他 Skill。來源：MK 實測，2026-11-02。

幾個我覺得有意思的地方：

  • 核心是 full-send（123 行）：順序是完成修改 → 拿到證據 → 用 sol-loop 找模型 review → 用 file-pr 開 PR → 用 babysit-pr 盯 CI → 合併 → 回報。
  • full-stop 才 47 行，基本上就是「full-send，但停在合併前一步」。
  • 整包只有一支真的程式：babysit-pr/scripts/pr-wait，其他通通是文字說明。

pr-wait 的說明輸出，以及三種停止條件 圖：我直接跑 pr-wait 的 --help，它只用 Python 標準函式庫，不用裝任何套件。來源：MK 實測，2026-11-02。

pr-wait 的用途是盯著一個 PR，有事件（CI 失敗、有人留言、review 機器人跑完）才印一行，讓 AI 被叫醒處理，沒事就安靜等。這個設計很聰明，省掉 AI 一直重複查狀態浪費的 token。

寫法值得抄的 3 個地方

就算你不打算用 tstack，這 9 份檔案也很適合拿來學「Skill 該怎麼寫」：

  1. 把「證據」講清楚。 full-send 規定證據必須是這次親眼看到的：指令輸出、重現步驟、截圖。還特別寫了「模擬測試全綠，不代表使用者體驗正常」，UI 改動要真的把程式跑起來看。光這句就能擋掉很多「AI 說改好了，其實沒好」的狀況。
  2. 把「什麼時候要問人」列成清單。 拿不到證據、合併門檻過不了、要刪資料或動到正式站、需求模糊到會影響結果、有別的 PR 讓這個 PR 變多餘，只有這幾種情況才停下來問；其他自己判斷，最後在報告裡交代。
  3. 刻意控制範圍。 council 和 sol-loop 都寫了「別讓反覆 review 變成越改越多」。sol-loop 預設最多 3 輪，只有資安、權限、資料遺失、併發這類重大問題還沒解決才延長到 5 輪，回來只剩小意見就提早收工。

另外 full-send 的合併門檻也很嚴：證據要涵蓋每個改動、必要檢查全綠、review 機器人跑完、沒有人還在要求修改，而且明文禁止用 --admin 繞過分支保護。

安裝

tstack README 的安裝指令與前置需求 圖：README 的 Install 與 Requirements 段落。來源：tstack 官方 README（授權 MIT）。

前置需求有三個：

  1. 已登入的 GitHub CLI（先跑 gh auth login）
  2. python3（給 pr-wait 用）
  3. council 和 sol-loop 需要能另外叫用其他廠商模型（README 說的 subagent）；README 說 T3 Code 內建 delegate_task 可以做到，其他工具要自己想辦法接
git clone https://github.com/t3dotgg/tstack
cp -R tstack/skills/* ~/.claude/skills/   # Claude Code
cp -R tstack/skills/* ~/.codex/skills/    # Codex

作者建議把個人設定（例如評審團要用哪些模型）寫在自己的 CLAUDE.md 或 AGENTS.md，之後更新 Skill 才不會被蓋掉。只想裝幾個也可以，但要連它依賴的一起裝，例如 takeover 需要 modernize、file-pr、babysit-pr、leaving-pr-comments。

注意事項

  • 說 full send 就等於授權：SKILL.md 寫明，這句話代表允許它合併、對自己的分支 --force-with-lease。我只會在有測試、有分支保護的 repo 這樣用。
  • council／sol-loop 要多家模型：如果你手上只有 Claude，這兩個（還有會呼叫 sol-loop 的 full-send）就沒辦法照原設計跑。council 還特別規定叫不到指定模型時要回報，不能隨便換別的模型頂替。
  • 費用：三家旗艦模型高推理 review 好幾輪，token 花得不少。
  • 偏 GitHub 工作流：pr-wait 認得 Greptile、Macroscope、CodeRabbit 這些 review 機器人，用 GitLab 的話要自己改。

MK 影片中 council 評審團的示意畫面 圖：我影片版裡 council 那一段的畫面（影片版在我的 FB Reels）。來源：MK 自製影片。

MK 觀點：適合誰、不適合誰

適合：每天開很多 PR、已經有 CI 和分支保護的工程師或小團隊。還有想學「Skill 怎麼寫」的人，這 9 份是我看過把「什麼時候該停下來問人」寫得最清楚的範本之一。

不適合：還沒有測試和 CI 的專案（沒有證據，full send 只會一直停下來問你）；只想聊天式寫程式、不碰 GitHub 流程的人；手上只有一家模型、又特別想用 council 的人。

常見問題

Q1：tstack 要錢嗎？ 不用，MIT 授權免費。但模型的訂閱或 API 費用照算，council 一次會用到三家。

Q2：只有 Claude Code 能跑 full send 嗎？ 沒辦法完整跑。full-send 的 review 步驟會呼叫 sol-loop，而 sol-loop 是請 OpenAI 的 GPT Sol 來看，你需要能叫到它的工具。

Q3：它會不會亂合併？ SKILL.md 有設合併門檻，也禁止繞過分支保護；不過最後還是看你的 CI 跟保護規則設得多嚴。

Q4：可以只裝其中幾個嗎？ 可以，記得把相依的一起裝，README 有列清楚哪個用到哪個。

延伸閱讀

追蹤 MK，掌握最新 AI 工具應用

每週分享 GitHub 飆星實測、AI 工具教學與提示詞，短影片版都在社群。

相關文章