Opus，尤其是 Opus 5，最近開始講一種誰也看不懂的話。不是技術上出錯，句子文法全對，邏輯也說得通，但讀起來像是把一份工程文件丟進翻譯軟體來回轉了三次：堆滿抽象名詞，句子拉得又長又繞，明明在講一個簡單決定，卻要包裝成一整段看似專業、實則空洞的措辭。Matt Pocock 說，他每次跟 Opus 對話，內容都直接飛過他的頭頂——不是聽不懂技術，是根本抓不到對方在說什麼。他試過用 output style 調整，試過在 agents.md 裡加規則，都沒用。
這是 Skills 專案 v1.2 版的起點，但不是全部。這套給 AI coding agent 用的工作方法，累積到這一版已經衝上 GitHub 全站第 24 名的星數榜，下載量早就不是一個人在用的規模。當一個工具紅到這個程度，它面對的問題也會跟著變：不再是「這個功能好不好用」，而是「不同的人、不同的模型、不同的工具，能不能聽懂同一套方法在說什麼」。這一版幾乎每個改動，拆開來看都在解同一件事。
治 Opus 說胡話的藥，不是叫它講白話
作者最後放棄硬修 Opus 本身，改做一個極簡的新技能，叫 /wait-what。用法簡單到近乎笨拙：AI 講出一段讀不懂的東西，你就回一句「等等，你剛剛說什麼？」，它就得重講一次。
技能內部只做兩件事。第一件是要求模型改用簡化技術英文的寫作規範，說白了就是講短句、講直述句、少用花腔。第二件才是關鍵：要求模型回頭對照 context.md 裡記錄的既有詞彙，用使用者自己在 Grill With Docs 過程裡定下來的說法重講一次。作者自己講得很直接——治好囉唆的藥方不是「講簡單一點」，而是「講你（使用者）的語言」。模型不是不會表達，是它預設的表達方式跟這個專案、這群人平常講話的方式對不上。逼它去查一份雙方共用的詞彙表，比要求它「精簡一點」有效得多。
Grill Me 從一問一答，改成追著問題的依賴關係跑
/grill-me 是這套技能裡最常被用到的一支，拷問使用者、把模糊需求問清楚。舊版每次只問一題，答完才問下一題。這個設計有個惱人的收尾：拷問到後段，難的問題早就問完了，剩下一堆瑣碎小事，還是一題一題來，使用者只能一路「好，可以，也可以」地應付，慢得讓人火大。
想加快，直覺做法是一次丟好幾題，但馬上冒出一個問題：如果第三題的答案要靠第一題先確定，一次全丟出來豈不是亂了套？作者的解法是把問題當成一張圖來看——某些問題彼此獨立，某些問題會在回答之後，才「打開」下一批問題。於是新版 Grill Me 改成按輪次推進：第一輪可能只有一題關鍵問題，答完之後，它牽動出的下一批問題才會在第二輪一起出現。畫面上每題還配一個建議答案，方便使用者用口述輸入快速過：同意、同意、這裡要改、那裡要改。這不是把拷問變隨便，而是把原本被迫線性排隊的問題，還原成它們本來的依賴結構，只在真正卡住的地方停下來一題一題問，其他地方能批就批。
一支技能的名字太窄，反而限制了它的用途
writing-for-agents 是舊技能「怎麼寫出好技能」的擴大版。作者發現自己一直拿這支技能去做別的事——凡是會被 agent 讀進去的文字，不管是不是技能檔，都可以套用同一套原則：寫得精簡、寫得讓輸出更可預期。於是它現在也能拿來改 agents.md、claude.md，順手解決一個他一直很不爽的毛病：那種把一堆規則全塞進對話開頭、讓每次對話都得先啃一大段文件的「前置塞爆」。把該講的東西挪進獨立的技能檔，agent 才需要的時候才去讀，而不是每次醒來都被硬灌一遍。這支技能本身也是模型可自動叫用的——只要它偵測到你正在改 agents.md，就會自己跳出來幫忙。
Wizard：寧可把控制權留在人類手上
Wizard 是這次真正的新東西，作者悄悄開發了幾個月才推出。起因是他最近要跑一輪 AWS 基礎設施的建置，過程繁瑣到讓他懷疑人生，心想這種事總該讓 agent 幫忙分擔一點。但他做出來的東西，恰恰不是把整段流程交給 agent 自動化——技術上他承認可以用 computer use 之類的方式讓 agent 直接登入操作，但他形容那種做法「感覺很不對勁」。
最後的設計是反過來：生成一份互動式的 bash 精靈，只走人類非做不可的那幾步——登入某個網站、貼上一組 API 金鑰、確認某個設定——其餘全部自動接手，存進該存的檔案、寫進 GitHub Secrets。整個過程完全是一支決定性的腳本，不涉及任何模型呼叫，不會把資料送去任何地方。這是這版裡少見的一個反例：多數技能都在教 agent 做更多事，Wizard 卻是刻意畫一條線，把「只能人做」的步驟留給人做，agent 負責把剩下的枯燥重複部分變得順手。作者說，這讓整套佈署流程從「痛苦」變成「莫名開心」——差別不在自動化了多少，而在於他終於清楚知道哪些事該交出去、哪些事不該。
拷問的對象，不一定坐在螢幕前
最後這支技能名字取得最不起眼，叫 to-questionnaire，但背後的場景最值得多想一層。作者用 Wayfinder 規劃自家後院要蓋一間花園辦公室，拷問到一半才意識到，真正該回答這些問題的人是他太太——這個空間她也要用，決定該兩人一起做。於是他把 agent 原本要問他的那批問題，轉成一份 markdown 文件，貼進 Google Docs 傳給太太，兩人一起過一遍、寫下答案，再把答案帶回對話裡。
這支技能解決的其實是個結構性缺口：拷問式對話預設「答問題的人就在這個視窗裡」，但真正該做決定的人，常常根本不在場，甚至不是 AI 的重度使用者、連 Slack 都沒裝。作者提到，有些團隊已經做到把 agent 拉進 Slack，讓利害關係人直接在對話串裡插話、agent 隨時可以接手——這是他心目中理想的協作方式。但多數人還沒走到那一步，一份能匯出、能在 Google Docs 上留言、不需要懂任何 AI 工具就能參與的文件，反而更實際。作者自己也說，他希望有一天能刪掉這支技能——因為它某種程度上是在補一個「agent 目前還不擅長多人協作」的洞，而不是解法本身。
這幾支看起來互不相干的技能——治療 Opus 廢話的 wait-what、把問題拆成依賴圖的新版 Grill Me、把寫作原則從技能檔擴大到所有 agent 讀的文字、刻意把控制權留給人類的 Wizard，以及把拷問內容翻成一份誰都看得懂的文件——放在一起看，其實都在做同一件事：把同一套方法，翻譯成不同模型、不同工具、不同的人都聽得懂的版本。一個工具紅了之後，真正變難的往往不是想法本身，而是這件事。