Godot Agent Skill 對比：haxqer/godot-skill、agent-skill-godot 與 GD-Agentic-Skills 該裝哪個

如果你的目標是用 VS Code + Codex + Godot 4.x 做第一個遊戲，不建議一開始就安裝一大堆 Godot Agent Skill。更穩的做法是先選一個規模可控、能服務目前工作流的專案，再把其他專案當作參考資料。

下面按「現在能不能用、適合怎麼用、有什麼風險」來對比四個 Godot Agent 相關專案。

結論先說

目前最適合先試的是 haxqer/godot-skill。它面向 Codex-compatible agents，覆蓋專案檢查、場景編輯、節點配置、腳本掛載、訊號連接、執行除錯和匯出包裝腳本，範圍比較集中。

fernforestgames/agent-skill-godot 更適合學習方法論，尤其是它對靜態型別、Godot 文件查詢、CLI 驗證、GUT 單元測試和編輯器 MCP 的要求很清楚。但它強依賴作者自己的 MCP 體系，不適合直接照搬。

GD-Agentic-Skills 更像一套 Godot Agent 知識庫，適合以後查資料，不建議初學階段全裝。

CODEXVault_GODOT 屬於最大化方案，適合後期自動建構、CI/CD 或團隊專案，第一個 Godot 遊戲暫時用不上。

1. haxqer/godot-skill：最適合先試

haxqer/godot-skill 的定位比較貼近 Codex 使用者。它明確面向 Codex-compatible agents，不是只為 Claude Code 寫的 Skill。

它覆蓋的能力包括：

• 專案檢查
• 場景編輯
• 節點配置
• 腳本掛載
• 訊號連接
• 執行和除錯
• 匯出包裝腳本

作者說明，場景編輯部分按目前 Godot 文件設計，並在 Godot 4.6.1 上做過本地驗證。雖然你的路線可能是 Godot 4.7，但兩者差距通常不會大到完全不可用。

這個專案的優點是規模相對集中，不會一開始就把 Agent 帶到複雜工程架構裡。對剛開始搭 VS Code + Codex + Godot 工作流的人來說，它更像一個可控的起點。

建議做法：

1. 可以安裝並閱讀。
2. 先在測試專案裡試，不要直接用於重要專案。
3. 允許它修改場景前，先用 Git 提交目前狀態。
4. 每次只讓它做一個小任務，例如掛載腳本、連接一個訊號或檢查一個場景。

需要注意的是，它目前專案規模和使用人數仍不算大，所以不要盲目信任每個腳本。對 .tscn 的自動修改尤其要看 git diff。

2. fernforestgames/agent-skill-godot：適合學習設計方法

fernforestgames/agent-skill-godot 的 SKILL.md 寫得比較清楚，很適合拿來學習一個 Godot Agent Skill 應該如何約束代理行為。

它特別值得參考的點包括：

• 強制使用靜態型別
• 修改前先檢查相關原始碼
• 動手前先查詢 Godot 文件
• 使用 Godot CLI 匯入和驗證
• 使用 GUT 執行單元測試
• 透過編輯器 MCP 取得場景樹、截圖和執行結果

這些規則本身很有價值。它們能減少 Agent 常見的幾個問題：憑空猜節點路徑、使用舊版 API、跳過驗證、一次改太多檔案。

但它也有明顯前提：它強依賴作者自己的 godot-docs 和 godot-editor 兩個 MCP，而且範例目錄仍然偏 Claude Code，例如 .claude/skills/...。

所以對 Codex 來說，它更適合閱讀和改造，不適合不加修改地全部照搬。可以把它裡面的規則抽出來，放進自己專案的 AGENTS.md，而不是直接複製整套目錄結構。

3. GD-Agentic-Skills：以後查資料，不建議現在全裝

GD-Agentic-Skills 的規模明顯更大。它目前有大約 96 個技能、27 個遊戲類型藍圖，包含大量靜態型別 GDScript 模式和工程結構。

它更像一套「Godot Agent 知識庫」，而不是一個簡單起步 Skill。

優點是覆蓋面很廣。遇到具體問題時，它可能能提供很好的參考，例如某類遊戲原型、某種 GDScript 模式、某個工程組織方式。

缺點也很明顯：

• 初學階段內容過多
• 容易讓 Agent 過度設計
• 小型遊戲可能被套上狀態機、事件匯流排、資源系統等複雜結構
• 安裝過多 Skill 會增加技能發現和選擇的干擾

Codex 官方也提醒過，大量技能可能導致初始技能列表被截短或省略。對初學者來說，這不是好事。你真正需要的是讓 Agent 更穩定，而不是讓它擁有更多不確定選擇。

建議：先收藏，不要全裝。等你遇到具體需求，例如「敵人狀態機怎麼寫」「俯視角射擊專案怎麼組織」「GDScript 靜態型別怎麼約束」，再針對性查。

4. CODEXVault_GODOT：現在暫時不用

CODEXVault_GODOT 明確把自己定位為「最大化方案」。它包含無頭環境、CI/CD、預提交檢查和多種支援腳本，甚至作者自己也建議按需求刪除不需要的工具鏈。

這種專案適合後期自動建構、團隊協作、持續整合和比較成熟的工程流程。

但對第一個 Godot 遊戲來說，它的問題是太重。你還沒有穩定的場景結構、腳本風格和驗證節奏時，引入一整套 CI/CD 和無頭建構流程，反而會分散注意力。

建議：暫時不用。等專案已經能穩定執行，且你開始需要自動匯出、跨平台建構、預提交檢查或團隊協作時，再回來評估。

推薦選擇順序

如果你現在剛開始搭 Godot + VS Code + Codex 工作流，可以按這個順序來：

1. 先用 haxqer/godot-skill 做小專案試驗。
2. 閱讀 fernforestgames/agent-skill-godot，把好的規則整理進自己的 AGENTS.md。
3. 把 GD-Agentic-Skills 當資料庫，需要時查，不要全裝。
4. 暫時跳過 CODEXVault_GODOT，等專案進入自動化建構階段再考慮。

最關鍵的一點是：不管用哪個 Skill，都不要讓 Agent 一次性接管整個 Godot 專案。

更安全的節奏是：

1
2
3
4
5
6
7
8
9

Git 提交目前狀態
        ↓
讓 Agent 只改一個小功能
        ↓
查看 diff
        ↓
在 Godot 中執行驗證
        ↓
成功後再提交

尤其是涉及 .tscn 場景檔案、訊號連接、節點重新命名和資源路徑時，一定要先看差異，再執行驗證。Godot 專案不是純腳本專案，場景樹和資源引用同樣是程式碼的一部分。

我的建議

如果你正在按 VS Code + Codex + Godot 4.7 的路線起步，先不要追求「最全 Skill」。先追求「可控」和「能回退」。

短期方案很簡單：

• 用 haxqer/godot-skill 試水；
• 把 fernforestgames/agent-skill-godot 的規則吸收到 AGENTS.md；
• 保持 Git 小步提交；
• 每次只讓 Codex 做一個可驗證任務；
• 複雜場景仍然優先在 Godot 編輯器裡手動搭節點。

這樣 Codex 更像一個可靠的 Godot 程式設計助手，而不是一個隨時可能把專案結構改複雜的自動化黑盒。