Context Engineering Kit：把提示詞拆成可安裝的插件，而不是一份大雜燴
Hand-crafted Claude Code Skills focused on improving agent results quality. Compatible with OpenCode, Cursor, Antigravity, Gemini CLI, and others. Includes CodeRabbit open-source alternative.
秒懂
- 它是什麼？
- NeoLabHQ 的 Context Engineering Kit 是一套以 agentskills.io 規格撰寫的 Claude Code Skills 集合，主打低 token 佔用與逐插件安裝。它的價值在於把「上下文工程」變成可選擇的模組，代價是 GPL-3.0 授權與跨工具支援的不一致。
- 適合誰用？
- 如果你每天在 Claude Code 裡做規格驅動或領域驅動的開發，而且願意逐個插件試用、接受 GPL-3.0 的授權條件，這個 marketplace 值得裝起來評估；若你只在 Gemini CLI 或 Antigravity 上工作，README 明說這兩個工具不支援逐插件選擇，裝下去的是一整包，需要自己刪掉不要的 skills 與 agents。若你的團隊無法接受 copyleft 條款，或你依賴 npx skills 這條路徑，請注意 README 指出該方式不支援 subagents，拿不到完整體驗。
- 可以商用嗎？
- 可以，但有條件。GPL-3.0 是 copyleft 授權：如果你散布包含它的軟體，就必須以同一授權公開該軟體的原始碼。只在內部執行、不對外散布，則不會觸發這項義務。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 20 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它想解決的是上下文被稀釋，不是模型不夠聰明
多數 agent 工作流的問題不在模型能力，而在你塞給它的東西。專案慣例、程式碼規範、審查規則全部混在同一段系統提示裡，結果是每次對話都帶著一堆這次任務用不到的資訊。Context Engineering Kit 的做法是把這些內容切成插件，README 的 Key Features 寫得很直接：每個插件只載入它自己的 agents、commands 與 skills，沒有重疊。
目標讀者是已經在用 Claude Code 或同類工具寫正式專案的人。README 說這些提示詞來自該公司開發者長期日常使用，另外補充了來自論文與其他專案的插件。這個來源說明了一件事：它不是為了展示提示詞技巧而生的收藏集，而是從實際工作流裡抽出來的。
它同時宣稱是 CodeRabbit 的開源替代方案。這一點在 README 裡只以一句話帶過，沒有對應的插件說明或功能對照，所以現階段很難判斷覆蓋範圍到哪裡。如果你的主要需求是自動化程式碼審查，這是需要自己去翻文件確認的部分，不能只看這句描述。
插件目錄結構：SDD、DDD、SADD、reflexion 各自負責什麼
從 README 的 News 段落可以拼出插件之間的關係。Spec-Driven Development（SDD）是規格驅動開發，v2.0.0 說它被從頭重寫，並且基於 Arc42 這套軟體開發文件標準。v3.1.0 進一步在 developer agent 裡嵌入 DDD 與 SOLID 規則，並加入專門的 code-reviewer agent，套用函式與 OOP 最佳實踐規則，再加上 Muda 浪費分析來降低程式複雜度與重複。
Subagent-Driven Development（SADD）在 v2.2.0 被描述成 SDD 的蒸餾版本，用 meta-judge 與 judge 兩個 sub-agent 在實作進行的同時、平行產生規格。這是兩種不同的節奏：SDD 先有規格再寫程式，SADD 讓規格與程式碼同步長出來。
DDD 插件在 v2.2.0 之後把 Clean Architecture、DDD、SOLID、函式式程式設計等範例當成規則，在寫程式時自動加進上下文。Tech Stack 插件在 v3.0.0 之後會在 agent 讀寫 TypeScript 檔案時自動注入 TypeScript 最佳實踐。reflexion 則對應 README 快速開始裡的 /reflect 指令。
這裡的設計取向很清楚：偏好 command-oriented skills 搭配 sub-agents，而不是塞一份通用資訊文件。代價是插件數量多，你得先讀懂每個插件管哪一段流程，才知道要裝哪幾個。
安裝路徑不是一條，每個工具的體驗落差很大
Claude Code 是唯一支援逐插件選擇的路徑。先加入 marketplace，再安裝單一插件：
/plugin marketplace add NeoLabHQ/context-engineering-kit /plugin install reflexion@NeoLabHQ/context-engineering-kit
README 特別說明，加入 marketplace 只是讓插件可供安裝，不會把 agents 或 skills 載入上下文，要等 install 之後才會。
Gemini CLI 走的是另一條：
gemini extensions install https://github.com/NeoLabHQ/context-engineering-kit
Antigravity CLI 直接從倉庫的 antigravity/ 目錄安裝，不需要 Gemini CLI：
agy plugin install https://github.com/NeoLabHQ/context-engineering-kit/antigravity
這兩條路徑的說明裡都附了同一句警告：會把每個插件的 skills 與 agents 當成單一 bundle 安裝，沒有 Claude Code 那種逐插件選擇，建議安裝後自行刪掉不需要的部分。這句話值得當成設計限制來讀，而不是安裝提示。
Cursor、Codex、OpenCode 等則透過 vercel-labs/skills：
npx skills add NeoLabHQ/context-engineering-kit
這條路徑可以挑選要裝哪些 skills，但 README 說每個 provider 有自己的 agent 格式，而且 npx skills 不支援 subagents，所以拿不到完整體驗。另外還有 OpenSkills 的替代安裝方式，指令是 npx openskills install 與 npx openskills sync。
reflexion 的實際用法：反思與記憶是兩個分開的動作
README 的快速開始示範了一段完整流程。先請 Claude 實作功能，再輸入 /reflect，它會分析結果並提出改進建議。README 描述了三種後續行為：問題明顯時直接修掉，問題輕微時提出建議讓你回應，你也可以直接說 fix the issues。
如果在初始提示裡就寫上 reflect 這個字，hook 會自動執行 /reflect，不需要另外下指令。使用這個 hook 需要先滿足一項設定條件，README 在此處被截斷，只留下「you need to have b」開頭的一行，所以無法確認完整的前置需求。這是文件不完整的地方。
另一個指令是 /memorize。README 的說明是，如果你想避免反思時發現的問題再次出現，可以請 Claude 萃取解法策略並存進專案記憶。把反思與記憶拆成兩個指令是合理的：反思是當下的診斷，記憶是跨對話的沉澱。但這也意味著你不下 /memorize，這次的教訓就只留在這次對話裡。
token 效率是設計主張，不是可驗證的數字
README 把 Token-Efficient 列為核心特色，理由是精心設計的提示詞與架構，並在可能時偏好 command-oriented skills 搭配 sub-agents，而非通用資訊 skills，以減少把無關資訊塞進上下文。
這個主張在架構層面說得通：插件之間不重疊、每個插件只載入自己的檔案，確實比一份萬用提示詞更省。但 README 沒有給出任何 token 數量、上下文佔用比例或前後對照。所以「低 token 佔用」目前只能當成設計原則來理解，不能當成量測結果。要評估實際佔用，得在安裝後自己看載入了哪些檔案。
同樣需要保留態度的還有 Scientifically proven 這一項。README 說插件基於經過可信基準與研究驗證的技術與模式，但沒有在 README 內列出對應的研究或基準名稱。v2.0.0 的說明裡有一句「能在真實生產專案中 99% 的情況下產生可運作程式碼」，這是很強的宣稱，README 沒有提供驗證方法或樣本。要採用前，這個數字應該在你自己的程式庫上重測。
GPL-3.0 與維護節奏：採用前要算的兩筆帳
授權是 GPL-3.0。這對內部開發流程通常不是問題，但如果你打算把這些 skills 或 agents 打包進要散布的產品，copyleft 條款會牽動你的散布方式。這不是法律意見，實際影響請找法務確認。
維護節奏可以從版本紀錄看出輪廓。v3.10.0 在 2026-08-26 發布，前一版 v3.9.1 是 2026-08-19，再前一版 v3.9.0 是 2026-08-18。三週內出了三個版本，patch 與 minor 交錯。對照 News 段落裡列出的 v2.0.0 到 v3.1.0 變更，SDD 插件被重寫過一次，SADD 的定位也被調整過。這代表插件行為可能隨版本改變，你調好的提示詞流程在下一次升級後未必一樣。
升級成本因此主要落在兩處：一是插件內部規則變動，二是跨工具安裝方式的差異。Gemini CLI 與 Antigravity 的使用者若刪過不需要的 skills，每次重新安裝都要再刪一次。
什麼情況下不該用它
如果你的工作環境沒有 subagent 機制，這套工具的核心設計就用不上。README 自己指出 npx skills 不支援 subagents，而 SADD 的 meta-judge 與 judge 正是靠 sub-agent 平行產生規格。少了這一層，你拿到的是被削弱的版本。
如果你只需要一個通用的程式碼審查助手，這個專案的插件粒度反而增加負擔。它的前提是你願意先理解 SDD、SADD、DDD 各自的流程定位，再決定裝哪幾個。只想裝一個萬用插件的人，會覺得這裡的選擇太多。
替代方案可以看 vercel-labs/skills。它同樣是透過 npx skills 安裝 skills 的工具，差別在於它是通用的 skills 安裝器，不綁定特定插件集，也不提供這套 kit 內的 SDD、DDD、SADD 等流程插件。換句話說，vercel-labs/skills 解決的是「怎麼把 skills 裝進不同 agent」，Context Engineering Kit 解決的是「裝進去的 skills 該包含哪些工程流程」。兩者可以並用，不是互斥選項。
至於 README 提到的 CodeRabbit 開源替代定位，由於文件沒有展開對應插件的功能範圍，這裡無法判斷它在哪些審查場景下能取代、哪些不能。
編輯結論
如果你每天在 Claude Code 裡做規格驅動或領域驅動的開發，而且願意逐個插件試用、接受 GPL-3.0 的授權條件，這個 marketplace 值得裝起來評估；若你只在 Gemini CLI 或 Antigravity 上工作，README 明說這兩個工具不支援逐插件選擇，裝下去的是一整包，需要自己刪掉不要的 skills 與 agents。若你的團隊無法接受 copyleft 條款，或你依賴 npx skills 這條路徑，請注意 README 指出該方式不支援 subagents，拿不到完整體驗。動手前先確認三件事：你的 agent 是否支援 subagent、你要裝的插件實際載入了哪些檔案、以及 v2.0.0 版本說明中「99% 情況下能產生可運作程式碼」這項宣稱在你自己的專案上是否成立。
社群筆記