測試驅動開發與軟體架構 Skills 指南

要修 bug、設計公開介面或釐清領域模型，該選哪個 Skill？

MissSkill Bench 編輯整理 · 2026/11/04。用途依各 Skill 已發布版本整理，未推論未測版本效果。

依任務對照用途與限制

生成測試或架構說明不代表專案已通過驗證。先確認需求與公開介面，再在自己的環境執行測試。

用途比較與個別實測入口
Skill 與任務	適合誰	先確認的限制
tdd 測試驅動開發與行為測試	想透過公開介面，以一題測試、一段最小實作逐步修正功能的開發者。	需求與測試邊界要先明確；生成測試程式碼不代表測試已實際通過。
codebase-design 軟體架構與模組介面設計	要比較模組邊界、簡化介面與改善可測性的開發者。	架構方案需結合程式碼證據；沒有適用所有專案的單一最佳結構。
domain-modeling 領域詞彙與軟體邊界釐清	需要統一業務詞彙、討論邊界案例與架構取捨的團隊。	不能代替領域專家的確認；不應把未驗證的推論寫成既定規則。
pydantic-models-py Pydantic v2 API 模型設計	需要區分建立、更新、回應與資料庫模型的 Python 開發者。	不會驗證實際資料庫或 API；別名、更新語意與驗證規則仍需專案測試。

以下是每個 Skill 實際使用的題目標題。點選題目可閱讀原文；進入詳情頁後可切換模型，核對前後回答與執行證據。

以公開介面與事先確認的 seam 進行垂直切片測試，每輪先寫一個會失敗的行為測試，再加入最小實作通過，避免內部耦合、同義反覆與橫向批次測試。

以深模組、介面、接縫、適配器、槓桿與局部性等一致詞彙評估軟體結構，透過刪除測試與多方案比較縮小呼叫者負擔並改善可測性。

透過釐清含糊詞彙、具體邊界案例與程式證據，持續維護不含實作細節的領域詞彙表；只有難逆轉、意外且存在真實取捨時才建立 ADR。

依 Pydantic v2 的多模型模式建立 Base、Create、Update、Response 與 InDB 類別，統一欄位別名、更新語意及資料庫文件形狀，減少 API 契約混用。