matt-pocock-skills · 開源

真正工程师的技能

我每天用来做真正工程的代理技能——而不是凭感觉编码。

开发真正的應用程式是困難的。像 GSD、BMAD 和 Spec-Kit 這樣的方法試圖透過掌控流程來提供幫助。但這樣做卻剝奪了你的控制權，使得流程中的錯誤難以解決。

這些技能設計得小巧、易於適應且可組合。它們適用於任何模型。它們基於數十年的工程經驗。去折騰它們吧。讓它們成為你自己的。享受吧。

如果你想跟上這些技能的更新，以及我創建的任何新技能，你可以加入我的電子報，已有約 6 萬名開發者訂閱：

訂閱電子報

為什麼存在這些技能

我開發這些技能是為了修復我在 Claude Code、Codex 以及其他編碼代理中看到的常見故障模式。

#1：代理沒有按照我的意願行事

"沒有人確切知道他們想要什麼"
David Thomas & Andrew Hunt，《程式設計師修煉之道》

問題。軟體開發中最常見的故障模式是錯位。你認為開發者知道你想要什麼。然後你看到他們構建的東西——你意識到它完全沒有理解你。

在人工智慧時代，這同樣如此。你和代理之間存在溝通差距。解決這個問題的方法是進行一次刨根問底會話——讓代理向你詢問關於你正在構建的內容的詳細問題。

解決方案是使用：

/grill-me — 用於非程式碼用途
/grill-with-docs — 與 /grill-me 相同，但增加了更多好東西（見下文）

這是我最受歡迎的技能。它們幫助你在開始之前與代理對齊，並深入思考你正在做的更改。每次你想進行更改時都使用它們。

#2：代理過於囉嗦

有了通用語言，開發者之間的對話和程式碼的表達都源自同一個領域模型。
Eric Evans，《領域驅動設計》

問題：在專案開始時，開發者和他們為其構建軟體的人（領域專家）通常說著不同的語言。

我在我的代理身上也感受到了同樣的緊張。代理通常被投入到專案中，並需要邊做邊弄清楚行話。所以它們用 20 個詞來表達只需 1 個詞就能說清楚的事。

解決方案是共享語言。它是一個幫助代理解碼專案中使用的行話的文件。

範例

這是我 course-video-manager 倉庫中的一個 CONTEXT.md 範例。哪一個更容易閱讀？

之前："當課程中某小節的一節課變為「真實」（即在檔案系統中被賦予一個位置）時，會出現一個問題"
之後："存在實體化級聯的問題"

這種簡潔性在每次會話中都得到回報。

這內建於 /grill-with-docs 中。它是一種刨根問底會話，但可以幫助你與 AI 建立共享語言，並將難以解釋的決策記錄在 ADR 中。

很難解釋這有多強大。它可能是這個倉庫裡最酷的技術。試試看吧。

提示

共享語言除了減少冗餘之外還有許多其他好處：

變數、函數和檔案使用共享語言一致地命名
因此，程式碼庫對代理來說更易於導航
代理在思考上也消耗更少的令牌，因為它可以使用更簡潔的語言

#3：程式碼無法運作

"始終採取小而謹慎的步驟。反饋的速度就是你的速度極限。永遠不要接受過於龐大的任務。"
David Thomas & Andrew Hunt，《程式設計師修煉之道》

問題：假設你和代理對要構建的內容達成一致。但代理仍然產出垃圾時會發生什麼？

是時候審視你的反饋迴圈了。如果對代理產出的程式碼實際運作情況沒有反饋，代理就像在盲目飛行。

解決方案：你需要通常的反饋迴圈組合：靜態型別、瀏覽器存取和自動化測試。

對於自動化測試，紅-綠-重構迴圈至關重要。這就是代理先編寫一個失敗的測試，然後修復測試。這有助於給代理提供一致的反饋水平，從而產出好得多的程式碼。

我構建了一個 /tdd 技能，你可以將其插入任何專案。它鼓勵紅-綠-重構，並為代理提供了大量關於什麼是好測試和壞測試的指導。

對於除錯，我還構建了一個 /diagnosing-bugs 技能，它將最佳除錯實踐封裝成一個簡單的迴圈。

#4：我們建了一個泥球

"每天投資於系統的設計。"
Kent Beck，《極限程式設計解析》

"最好的模組是深模組。它們允許透過一個簡單的介面存取大量功能。"
John Ousterhout，《軟體設計哲學》

問題：大多數用代理構建的應用程式都很複雜且難以更改。因為代理可以極大加速編碼，它們也加速了軟體熵。程式碼庫以前所未有的速度變得更複雜。

解決方案是採用一種全新的 AI 驅動開發方法：關注程式碼的設計。

這內建於這些技能的每一層：

/to-spec 在建立規範之前詢問你正在觸及哪些模組

而關鍵在於，/improve-codebase-architecture 幫助你拯救一個已經變成泥球的程式碼庫。我建議每隔幾天在你的程式碼庫上執行一次。

總結

軟體工程基礎比以往任何時候都重要。這些技能是我盡力將這些基礎濃縮成可重複實踐的結果，以幫助你發佈職業生涯中最好的應用程式。享受吧。

參考

這些技能按照一個軸劃分——誰可以調用它們。用戶調用的技能只有在你輸入它們時才可存取（例如 /grill-me）；它們的工作是編排。模型調用的技能可以由你調用，或者在任務合適時由代理自動觸及；它們包含可重複的規程。用戶調用的技能可以調用模型調用的技能，但絕不能調用另一個用戶調用的技能。

工程

我每天用於編碼工作的技能。

用戶調用

ask-matt — 詢問哪個技能或流程適合你的情況。它是本倉庫中用戶調用技能的路由器。
grill-with-docs — 建立專案領域模型的刨根問底會話，同時精煉術語並內聯更新 CONTEXT.md 和 ADR。
triage — 透過分類角色的狀態機移動問題。
improve-codebase-architecture — 掃描程式碼庫以尋找深化機會，將其呈現為視覺化 HTML 報告，然後對你選擇的任何一個進行刨根問底。
setup-matt-pocock-skills — 為工程技能設定此倉庫（問題跟蹤器、分類標籤、領域文件佈局）。在使用其他工程技能之前，每個倉庫執行一次。
to-spec — 將目前對話轉化為規範並發佈到問題跟蹤器。無需採訪——僅綜合你已經討論的內容。
to-tickets — 將任何計劃、規範或對話分解為一組探路者式票據，每個票據宣告其阻塞邊緣——以本地文件中的文字形式或真實跟蹤器上的原生阻塞連結形式編寫。
implement — 構建規範或一組票據所描述的工作，在預先約定的接縫處驅動 /tdd，並在提交前以 /code-review 結束。
wayfinder — 將一大塊工作（超過一個代理會話能容納的量）規劃為問題跟蹤器上的調查票據共享地圖——逐個解決它們，直到通往目的地的路徑清晰。

模型調用

prototype — 構建一次性原型來回答設計問題——對於狀態/邏輯問題，可執行的終端應用程式，或者從一個路由切換的幾種完全不同的 UI 變體。
diagnosing-bugs — 針對難以處理的錯誤和效能退化進行有紀律的診斷迴圈：複現 → 最小化 → 假設 → 檢測 → 修復 → 迴歸測試。
research — 基於高信任度的一手來源調查一個問題，並將發現作為帶引用的 Markdown 文件保存在倉庫中，作為後臺代理執行。
tdd — 採用紅-綠-重構迴圈的測試驅動開發。每次構建一個垂直切片的功能或修復錯誤。
domain-modeling — 主動構建和完善專案的領域模型——對照術語表挑戰術語，用邊緣情境進行壓力測試，並內聯更新 CONTEXT.md 和 ADR。
codebase-design — 設計深模組的共享規程和詞彙：一個小的介面背後包含大量行為，放置在乾淨的接縫處，可透過該介面進行測試。
code-review — 自固定點以來的差異兩軸審查：標準（是否遵循倉庫的編碼標準，加上 Fowler 的壞味道基線？）和規範（是否忠實地實現了原始問題/PRD？），作為並行子代理執行，互不污染。

生產力

通用工作流工具，非程式碼特定。