moyu-ko
作者 uuczmoyu-ko 是一個程式碼編輯技能，強調把變更控制得精簡、聚焦、方便審查。它能避免過度工程化：只修改明確要求的檔案、採用最簡單可行的修正方式，並在範圍不清楚時先提問。當你需要精準 diff、聚焦式 bug 修復，以及一份實用的 moyu-ko 紀律化程式碼編輯指南時，這個技能就很適合。
這個技能的評分是 68/100，代表它可以上架，但更適合被定位成一個聚焦、帶有明確立場的工作流程輔助，而不是全面成熟的安裝方案。對目錄使用者來說，它的用途很清楚——避免過度工程化的編輯——但儲存庫缺少周邊文件與操作資產，因此導入時仍會有一些猜測成本。
- 觸發條件非常明確：前言直接寫明，當偵測到過度工程化模式時會啟動，且提供了細緻的 9 點觸發清單。
- 操作意圖很強：內文定義了具體的編輯哲學，核心是最小化 diff、限制變更範圍，以及在擴大工作前先詢問。
- 對小眾受眾有很好的安裝決策價值：這個技能明確說明何時適用，以及它會強制什麼行為。
- 支援基礎較薄弱：除了 `SKILL.md` 之外，沒有 scripts、references、resources、rules 或 readme files 來補充使用方式。
- description 非常短，而且儲存庫缺少 workflow examples，因此使用者必須自行推斷代理在實際任務中應如何套用這項 policy。
moyu-ko skill 概覽
moyu-ko 的用途
moyu-ko 是一個程式碼編輯 skill，目標是在過度設計發生之前先擋下來。它幫助 AI 只做最小且正確的變更，維持在使用者要求的範圍內，並避免額外加入抽象層、測試、文件或依賴，除非有被明確要求。
適合安裝的人
如果你常常希望 AI 只修補既有程式碼、修一個範圍很窄的 bug，或做最小修改而不是整個重寫，就適合安裝 moyu-ko skill。這很適合重視精準 diff、審查速度，以及盡量降低實作變動量的團隊。
它的不同之處
不同於只是說「請保持精簡」的通用提示，moyu-ko 把明確的防護規則寫進去：只改指定檔案、優先採用最簡單的實作、如果需求不清楚就先停下來詢問。這讓它在 moyu-ko for Code Editing 這類情境中特別有用，因為此時範圍控制比大規模重構更重要。
如何使用 moyu-ko skill
安裝並啟用
先依照目錄的標準安裝流程完成 moyu-ko install 這一步，接著把它用在明確屬於程式碼編輯的任務上。很適合的觸發方式例如：Use moyu-ko to make only the minimal change needed to fix this bug in src/auth.ts.
給 skill 一個有界定的任務
moyu-ko usage 的最佳用法，是把下列事項說清楚：
- 要動到的精確檔案或路徑
- 你想要的行為變更
- 哪些部分絕對不能改
- 已知限制，例如「不能新增依賴」或「不要加測試」
較強的輸入：
Update
src/cart.tsso the discount only applies to logged-in users. Do not change other pricing logic or create new files.
較弱的輸入：
Improve the checkout flow.
先讀對的檔案
想要最快進入 moyu-ko guide 的工作流程，先看 SKILL.md，再檢查你 repo 裡定義變更範圍的那些檔案。由於這個 skill repository 刻意保持精簡，重點在理解行為規則，而不是去翻找更多支援資料夾。
用最小 diff 來發出提示
當你希望 skill 配合得好，請直接要求它做最小可能的修改，並明講任何硬性限制。比如：
Use moyu-ko to patch
api.ts. Change only the validation branch, avoid new helpers, and ask before touching any other file.
moyu-ko skill 常見問題
moyu-ko 只適合程式碼編輯嗎？
是的，這就是它的設計用途。moyu-ko skill 著重的是有紀律地編輯，而不是廣泛規劃、架構設計，或從零開始搭建骨架。如果你需要的是重新設計，普通提示詞可能更適合。
什麼時候不該用 moyu-ko？
當你其實是希望 AI 探索多種作法、加入支援性測試，或順手清理相鄰程式碼時，就不該用 moyu-ko。它的價值在於範圍控制，所以對於開放式重構往往不是最佳選擇。
它適合新手嗎？
可以，只要你能把變更講清楚。這個 skill 的規則很簡單，但只有在需求本身已經有邊界時表現最好。新手若能把檔案、行為，以及「不要動哪些地方」列出來，通常效果最好。
它和一般提示詞有什麼不同？
一般提示詞也可以要求最小變更，但 moyu-ko 會把這件事變成預設的運作模式。如此一來，當你只想做聚焦的編輯時，就比較不會意外重寫、額外加入抽象層，或多生出其他檔案。
如何改進 moyu-ko skill
提供更精準的範圍指示
品質提升最大的地方，就是把編輯範圍縮小。請明確指出檔案、要改動的最小區塊，以及你預期的結果。要求越精準，moyu-ko 就越不容易卡在釐清需求，或把修改做過頭。
加上明確邊界
如果有任何部分必須維持不動，就直接說明。實用的邊界包括：
- “no new helper functions”
- “no new dependencies”
- “do not change public APIs”
- “keep the diff under 10 lines if possible”
這些限制能幫助 moyu-ko for Code Editing 產出更利於審查的結果。
當任務有歧義時，預期它會提問
常見失敗模式之一，是把目標描述得太少，卻期待模型自行補完。如果需求可能影響其他檔案，或需要新的抽象層，moyu-ko 應該先停下來發問。這是特性，不是問題。
針對第一版修補再迭代，不要整個計畫一起放大
如果第一次輸出範圍太大，下一步要收緊指令，而不是把任務越講越大。比方說，要求它「只改解析輸入的那一行」，而不是「把整個 module 整理一下」。這樣能讓 moyu-ko usage 一直維持在它的最小變更設計上。