codebase-design (mattpocock/skills)
提供設計深模組的共同詞彙，強調小介面、清楚接縫與可測試性。
codebase-design：讓架構審查具備深度詞彙與更清楚的結構（對照組 3.2、技能 3.9、一句話提示 4.5），Token 用量是 1.1 倍，但它找到的植入問題並沒有比一句話提示更多
Codex CLI · gpt-6-astra
23.6 / 30
相對未使用技能的提升：+0.71 · 視情況推薦 · 18 次執行
視情況推薦：提升幅度 +0.71 低於 +1.0。推薦條件為總分至少 22/30、產出品質至少 3.5、提升幅度至少 +1.0。
SOTA
透過使用 Codex 測試。
涵蓋 Codex, Claude Code
Codex CLI 0.166（SOTA 等級）：18 次評分執行。依我們的等級規則，在這裡通過也涵蓋 Claude Code；但這不代表第二等級的結果。
分數
每個維度為 0 到 5 分，六個維度相加即為滿分 30 的總分。每個維度都是 5 分最好。成本 5 分代表便宜又快速；安裝 5 分代表容易安裝。
- 觸發可靠性
- 5.0
- 相對未使用技能的提升
- 2.7
- 產出品質
- 3.9
- Token 與時間成本
- 4.0
- 安裝與可攜性
- 4.0
- 安全性
- 4.0
安全審查
安全靜態掃描：0 CRITICAL / 0 HIGH / 0 MEDIUM。人工審查：可在無網路沙箱中安全執行（未發現問題）。掃描結果乾淨，不代表技能一定安全。
安裝
npx skills@latest add mattpocock/skills --skill codebase-design
固定 Commit: 4ae2317ddb22b046e26455e4f9c9b3aaaf62212d
測試日期: 2026-11-02
我們測了什麼
- 全儲存庫架構掃描 — 審查這個小型商店後端的架構改善空間：哪裡重新結構化會讓程式碼更容易修改、更容易測試？把你的發現寫成一份自包含的 HTML 報告，命名為 report.html 並放在這個資料夾（不要開啟瀏覽器或啟動伺服器…
- 只看付款與庫存 — 只看這個後端的付款與庫存部分，告訴我哪些重新結構化會帶來效益。把你的發現寫成一份自包含的 HTML 報告，命名為 report.html 並放在這個資料夾（不要開啟瀏覽器或啟動伺服器），且不要修改任何程式碼…
- 為什麼 place_order 難以測試？ — 這個後端裡的 place_order 要寫出像樣的測試感覺很痛苦。為什麼，什麼樣的重新結構化能解決？不要修改任何檔案；在最後的訊息中回答。
優點
- 相對未使用技能，平均分數從 3.21 提升到 3.92（+0.71）。
- 技能即使未被點名也會被採用：6/6 次實驗組執行都讀取了技能檔案。
缺點
- 一句話提示得分 4.54，使用技能則為 3.92（-0.63）。
- 每個任務的每個組別 n=2；約 1 分以內的差異屬於雜訊。
評測
Codex CLI 0.166（gpt-6-astra，低推理）在專用的 Windows 測試電腦上執行，每次執行都使用全新的暫存專案與暫存 HOME/TMPDIR/快取；技能已安裝（實驗組）、未安裝（對照組），或未安裝但把技能的核心要求壓縮成一句話附加到提示詞（一句話提示組）。每個任務的每個組別執行 2 次，關閉網路，封鎖 /tmp 寫入。提示詞從未提及技能（除下方註明的措辭外）。一個小型商店後端，埋了六個摩擦點（過淺的驗證器與金流包裝、只是轉發的庫存服務、單一的付款轉接器、重複的邏輯等）。任務：撰寫一份架構改善的 HTML 報告、只針對付款與庫存撰寫報告，以及回答「place_order 為什麼難以測試、你會怎麼修」（在對話中回答）。提示詞沒有點名任何設計術語。一句話提示組說明了深度概念與應該標記的重點。
三組對照
| 組別 | 平均分數（0-5） | 每次執行 Token 用量 |
|---|---|---|
| 未使用技能 | 3.21 | 119k |
| 一句話提示 | 4.54 | 114k |
| 使用技能 | 3.92 | 133k |
以 Codex CLI 執行 18 次，採規則式檢查評分，不經 LLM 評審。總分 23.6 / 30，評級為 視情況推薦。
評定：視情況（23.6 / 30）。 來源：mattpocock/skills，skills/engineering/codebase-design，固定於 commit 4ae2317。安裝：npx skills@latest add mattpocock/skills --skill codebase-design。授權： MIT（儲存庫 LICENSE）。
這是什麼
codebase-design 技能（mattpocock/skills）：一套以模組深度審視架構的方法：深模組以小小的介面隱藏大量行為；指出淺層的單純轉接模組、只存在於假想中的單一轉接器接縫、重複的邏輯，以及只能透過輔助函式測試的行為；說明接縫應該放在哪裡，讓行為能透過介面來測試。
我們如何測試
在專用的 Windows 測試 PC 上使用 Codex CLI 0.166（gpt-6-astra、低推理），每次執行都使用全新的臨時專案與臨時 HOME/TMPDIR/快取，安裝技能（使用技能組）、不安裝（對照組），或是不安裝但把技能核心要求濃縮成一句話附加在提示詞後（一句話組）；每個任務的每組各執行 2 次，關閉網路、封鎖 /tmp 寫入。提示詞完全沒有提到技能名稱（下述措辭除外）。
一個小型商店後端，埋了六個摩擦點（淺層驗證器與金額包裝器、單純轉接的庫存服務、單一付款轉接器、重複邏輯等）。任務：撰寫一份架構改善的 HTML 報告、一份只看付款與庫存的報告，以及「place_order 為什麼難以測試、你會怎麼修」（在對話中回答）。提示詞沒有指名任何設計術語。一句話提示則說明深度概念與要指出的項目。
- 整個儲存庫的架構掃描 — 請審視這個小型商店後端的架構改善空間：調整結構後，哪裡能讓程式更容易修改、也更容易測試？把發現寫成一份可獨立運作的 HTML 報告，命名為 report.html 放在這個資料夾（請勿開啟瀏覽器或啟動伺…
- 只看付款與庫存 — 只看這個後端的付款與庫存部分，告訴我哪些結構調整能帶來效益。把發現寫成一份可獨立運作的 HTML 報告，命名為 report.html 放在這個資料夾（請勿開啟瀏覽器或啟動伺服器），並且不要變更任何程…
- place_order 為什麼難以測試？ — 在這個後端裡，要為 place_order 寫出像樣的測試感覺很痛苦。為什麼會這樣，什麼樣的結構調整能解決？請勿變更任何檔案；在最後的訊息中回答。
評分採程式化方式（隱藏測試／植入問題召回／限制條件檢查／視情況搭配渲染＋OCR），每次執行 0–5 分。所有分數都不是由 LLM 評審決定。
結果
給第三組的一句話提示："以深度評斷模組：深模組以小小的介面隱藏大量行為；指出淺層的單純轉接模組、假想中的單一轉接器接縫、重複的邏輯，以及只能透過輔助函式測試的行為，並說明接縫應該放在哪裡，讓行為能透過介面來測試。"
| 任務 | 對照組分數 | 一句話提示 | 使用技能 | 對照組 token | 一句話組 token | 使用技能 token | 技能讀取 |
|---|---|---|---|---|---|---|---|
| t1-scan | 2.54 | 3.63 | 3.83 | 135k | 135k | 177k | 2/2 |
| t2-focus | 2.5 | 5.0 | 3.75 | 153k | 139k | 148k | 2/2 |
| t3-testing | 4.58 | 5.0 | 4.17 | 65k | 65k | 72k | 2/2 |
平均分數：未使用技能 3.21，使用技能 3.92（差異 +0.71）。每次執行 token：119k 對 133k（1.12x）；時間 154 秒對 158 秒。一句話組：4.54（技能相對一句話提示的增益：-0.63；一句話提示相對未使用技能的增益：+1.34）；一句話組每次執行 114k token，因此技能成本是一句話提示的 1.17 倍。
實際情況
- 對照組 3.21、使用技能 3.92、一句話組 4.54（各 n=6）。沒有指引時，HTML 報告幾乎沒用到架構詞彙（deep/shallow/seam/interface 僅出現 0-2 次，而檢查要求 6 次），4 次報告執行中 4 次如此。使用技能的報告 4 次全都用了，一句話組也一樣。
- 整個後端掃描：使用技能 4.24 與 3.41，一句話組 3.41 與 3.86，對照組 2.88 與 2.2。兩個有指引的組別都找到 6 個植入點中的 3–4 個；淺層驗證器包裝器與單一付款轉接器，各組都有幾次執行漏掉。
- 只看付款與庫存的任務：使用技能兩次都是 3.75，對照組兩次都是 2.5，一句話組兩次都是 5.0。使用技能與對照組的執行都只找到兩個點中的一個（漏掉假想中的單一付款轉接器）；一句話組兩個都找到。
- place_order 為什麼難以測試：各組差距不大（對照組 4.17 與 5.0，使用技能 4.17 與 4.17，一句話組 5.0 與 5.0）；使用技能的執行有一次漏掉一個原因（只透過輔助函式測試），另一次漏掉單純轉接層。
- Token：每次執行使用技能 133k、一句話組 114k、對照組 119k（對照組的 1.12 倍）。技能在 6/6 次使用技能組執行中都被讀取。
面向分數
| 面向 | 分數 | 原因 |
|---|---|---|
| 1_output_quality | 3.92 | 使用技能時平均 3.92/5（程式化檢查，見各任務表）。 |
| 2_lift_vs_no_skill | 2.71 | 相對未使用技能的 3.21 提升 +0.71 分（每個任務 n=2；約 1 分以下屬雜訊）。 |
| 3_trigger | 5.0 | 使用技能組 6/6 次執行都讀取技能檔案。 |
| 4_instructions_portability | 4 | SKILL.md 加上幾份參考檔案。 |
| 5_efficiency | 4 | token 1.12x（每次執行 133k 對 119k）、時間 1.03x（158 秒對 154 秒）。 |
| 6_safety_hygiene | 4 | 只有文字說明；請見 security.md。 |
這項測試的限制
- 對報告文字做規則式召回檢查（檔名附近的關鍵字）與詞彙計數；沒有判斷提出的結構調整是否合理，也沒有用瀏覽器開啟報告。
- 詞彙檢查會獎勵技能本身的術語，而一句話提示也提到這些術語，因此對有指引的組別較有利。
- 「前後對比」檢查只在掃描任務中出現 2 次未通過；不具區別力。
- 每個組合 n=2；只有一個小型程式庫。
- 每組每任務 n = 2：約 1 分以下的差異屬雜訊。
- 規則式評分只能衡量檢查項目看得到的部分，無法判斷品味，也無法判斷結果是否為最佳。
安全性
請見 security.md。掃描：CRITICAL 0 / HIGH 0 / MEDIUM 0。評定：可安全執行（無網路沙盒）。掃描乾淨並不代表技能安全。
總結
這項技能確實能讓審查具備單純提示所缺的模組深度框架，分數也比對照組略高；但同樣的概念寫成一句話，能用更少的 token 找到更多植入問題，因此增益多屬風格層面。
完整紀錄
執行日誌：codebase-design (Codex CLI, network off, per-run temp HOME/TMPDIR, one row per graded run.) 欄位：任務、組-輪次、得分（0-5）、token、秒、通過的檢查、代理開啟的 skill 檔案。 t1-scan control-1: 得分 2.88, token 135577, 秒 182.2, 檢查 4/6, 未開啟 t1-scan control-2: 得分 2.2, token 136096, 秒 168.8, 檢查 4/6, 未開啟 t1-scan oneliner-1: 得分 3.86, token 135437, 秒 152.3, 檢查 5/6, 未開啟 t1-scan oneliner-2: 得分 3.41, token 135611, 秒 172.2, 檢查 4/6, 未開啟 t1-scan treatment-1: 得分 3.41, token 176681, 秒 216.0, 檢查 4/6, 開啟 codebase-design t1-scan treatment-2: 得分 4.24, token 178425, 秒 181.7, 檢查 6/6, 開啟 codebase-design t2-focus control-1: 得分 2.5, token 164638, 秒 128.2, 檢查 2/4, 未開啟 t2-focus control-2: 得分 2.5, token 143158, 秒 298.9, 檢查 2/4, 未開啟 t2-focus oneliner-1: 得分 5.0, token 112021, 秒 375.7, 檢查 4/4, 未開啟
18 次執行、3 個產出檔案
範例產出
SOTA · 装了 skill：report.html（t1-scan，第 1 次，Codex）
<!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>Small shop backend — architecture review</title> <style> :root{color-scheme:light;--ink:#183047;--muted:#506276;--accent:#116b66;--line:#d8e2e8}*{box-sizing:border-box}body{margin:0;background:#f3f6f8;color:var(--ink);font:16px/1.65 system-ui,sans-serif}main{max-width:1060px;margin:auto;padding:48px 28px 70px}header{border-top:6px solid var(--accent);padding:24px 0}h1{font-size:2.5rem;line-height:1.15;letter-spacing:-.04em}h2{font-size:1.55rem;margin-top:0}h3{font-size:1.1rem;margin-bottom:6px}p{margin:10px 0 18px}.eyebrow,.meta{color:var(--muted)}.eyebrow{text-transform:uppercase;letter-spacing:.13em;font-size:.8rem;font-weight:700}section{background:white;border:1px solid var(--line);border-radius:12px;padding:26px;margin:22px 0}code,pre{font-family:Consolas,monospace;font-size:.9em}code{overflow-wrap:anywhere}pre{background:#edf4f5;padding:18px;white-space:pre-wrap;border-left:4px solid var(--accent)}table{width:100%;border-collapse:collapse;font-size:.93rem}th,td{text-align:left;vertical-align:top;padding:12px;border-bottom:1px solid var(--line)}th{background:#edf4f5}a{color:var(--accent)}.tag{display:inline-block;background:#e3f2ef;color:#155b53;border-radius:20px;padding:3px 10px;font-size:.8rem;font-weight:700}.note{border-left:4px solid #d1a03b;padding-left:16px}.flow{display:flex;gap:12px;flex-wrap:wrap;margin:18px 0}.flow div{flex:1;min-width:180px;background:#edf4f5;padding:16px;border-radius:8px}li{margin:8px 0}@media(max-width:650px){main{padding:24px 14px}section{padding:18px}h1{font-size:2rem}table{font-size:.83rem}th,td{padding:7px}}@media print{body{background:white}main{padding:0}section{break-inside:avoid}a{color:inherit}} </style> </head> <body><main> <header><div class="eyebrow">Architecture review · 2 November 2026</div> <h1>Make pricing and ordering the test surface.</h1> <p>The highest-value restructuring is to concentrate pricing policy in one pure module and let an order module own validation, stock decisions, and payment sequencing behind a small interface. Remove pass-through layers as this happens. This backend is small enough that a framework, generic repository hierarchy, or distributed decomposition would add more work than leverage.</p> <p class="meta">Scope: all ten Python files in <code>shop/</code>, <code>tests/test_helpers.py</code>, and the README. This report proposes changes; no application or test files were edited. Source references use the line numbers of the reviewed snapshot.</p> <nav aria-label="Report contents"><a href="#pricing">Pricing</a> · <a href="#orders">Order module</a> · <a href="#stock">Stock consistency</a> · <a href="#validation">Validation</a> · <a href="#plan">Migration & tests</a></nav> </header> <section><h2>Current structure and where knowledge leaks</h2> <pre aria-label="Current dependency diagram">cart ──→ money pricing (discount implementation) └── own discount rules ↑ imported by orders, never called orders ──→ validators + money + own discount rules ├─→ inventory_service ──→ inventory_repo ──→ g [... excerpt: first 3200 of 17083 characters]