56 個 Claude Code 指令
一個老闆的實戰指令庫

--- description: 只給最終結果，不解釋 --- 直接輸出最終結果。 規則： -不要開場白 -不要說明你做了什麼 -不要結尾總結 -不要問我要不要調整 -只輸出可以直接使用的成品本身 $ARGUMENTS

--- description: 用最短的方式回答 --- 用最少的字回答。能用一句話講完就用一句話。 不補充、不舉例、不加註解。 如果答案是數字或選項，就只給數字或選項。 $ARGUMENTS

--- description: 最多五行講完 --- 用最多五行回答。 第一行放結論，後面幾行放理由或條件。 不要開場白，不要總結段。 $ARGUMENTS

--- description: 展開講細節 --- 把以下主題完整展開說明。 要包含： -背後的原理或機制 -至少兩個具體例子 -常見的誤解或錯誤做法 -什麼情況下這個做法會失效 不要為了湊字數重複同一件事。 $ARGUMENTS

--- description: 拆成編號步驟 --- 把以下任務拆成編號步驟。 每一步要包含： -動作（一句話，動詞開頭） -完成的判斷標準（怎麼知道這步做完了） -常見的卡點 步驟數量控制在 10 步以內。超過就先分階段。 $ARGUMENTS

--- description: 產出可勾選的清單 --- 把以下內容整理成 Markdown checkbox 清單。 規則： -每一項都要是可以判斷「做了/沒做」的具體動作 -不要出現「注意」「留意」這種無法勾選的項目 -有先後依賴關係的用縮排表示 -最後獨立一區列出「常被漏掉的項目」 $ARGUMENTS

--- description: 整理成一套可複用的框架 --- 把以下內容整理成一套框架。 輸出格式： 1.框架名稱（好記，四個字以內） 2.這個框架解決什麼問題 3.組成要素（3-5 個，每個一句話定義） 4.使用順序或判斷流程 5.一個套用範例 6.這個框架不適用的情況 不要硬湊要素數量。三個就三個。 $ARGUMENTS

--- description: 產出完整執行計畫 --- 針對以下任務，產出可執行的計畫。 必須包含： -目標（可衡量的） -階段拆解，每階段的產出物 -每階段預估時間 -需要的人力與角色 -需要的預算或資源（不確定的標「待估」，不要編數字） -前置依賴（什麼沒完成就不能開始下一步） -最可能失敗的三個環節 $ARGUMENTS

--- description: 寫成可重複執行的標準流程 --- 把以下工作寫成一份任何人接手都能執行的流程文件。 結構： -這份流程什麼時候啟動（觸發條件） -執行前要準備什麼 -逐步操作（每步寫清楚在哪裡做、點什麼、填什麼） -每步的輸出物 -異常處理：三種最常見的狀況與對應做法 -完成後要通知誰 假設讀的人完全沒做過這件事，也不熟公司內部術語。 $ARGUMENTS

--- description: 排出帶時間軸的推進計畫 --- 把以下目標排成時間軸。 要求： -用週或月為單位 -每個時間段標明：要完成什麼、由誰、產出什麼 -標出關鍵節點（過了這個點就不能回頭的決策） -標出並行與序列：哪些可以同時做，哪些必須等 -最後列出三個會讓整個時程延誤的風險 不要給模糊的時間，寫不出來就標「待定，取決於 X」。 $ARGUMENTS

--- description: 深度拆解問題 --- 用分析師的角度拆解以下問題。 流程： 1.把問題重新定義成更精確的版本（原本的問法可能問錯了） 2.拆成 3-5 個子問題 3.每個子問題：目前已知什麼、缺什麼資訊 4.指出哪一個子問題是真正的關鍵，其他是次要的 5.列出你的分析建立在哪些假設上 $ARGUMENTS

--- description: 只挑毛病，不給任何肯定 --- 用最嚴格的角度批評以下內容。 規則： -不要說任何優點 -不要用「不過整體來說還不錯」這類緩衝 -每一個問題都要指出具體位置與具體理由 -依嚴重程度排序，最致命的放第一 -最後一句寫：如果只能改一個地方，改哪裡 如果真的找不到問題，直接說「找不到明顯問題」，不要為了交差硬編。 $ARGUMENTS

--- description: 改良現有內容並說明改動理由 --- 改良以下內容。 輸出兩部分： 1.改良後的完整版本 2.改動清單：每一處改了什麼、為什麼改 規則： -保留原本的核心意圖，不要改成另一個東西 -每一處改動都要有明確理由，不做風格上的個人偏好調整 -如果某個部分本來就沒問題，就不要動它 $ARGUMENTS

--- description: 改寫成新手也看得懂的版本 --- 把以下內容改寫成沒有相關背景的人也能理解的版本。 規則： -不用專業術語。必須用的時候，第一次出現用括號解釋 -用日常生活的類比說明抽象概念 -拆成短句，一句話講一件事 -保留所有關鍵資訊，不要為了簡化而漏掉重點 $ARGUMENTS

--- description: 用最白話的方式解釋 --- 用最白話的方式解釋以下概念。 規則： -假設對方完全沒有任何背景知識 -先給一個生活中的類比，再講實際的東西 -完全不用專業術語 -三段以內講完 -最後一句：所以這件事的重點是什麼 $ARGUMENTS

--- description: 深入到底層機制 --- 把以下主題挖到底。 層次： 1.表層：一般人的認知是什麼 2.中層：實際運作機制 3.底層：為什麼會是這樣（歷史、結構或誘因上的原因） 4.邊界：這個理解在什麼情況下會失效 5.爭議：這個領域裡目前還沒有共識的部分 如果某一層你不確定，明說不確定，不要用推測填滿。 $ARGUMENTS

--- description: 逐項比較多個選項 --- 比較以下選項。 輸出： 1.一張 Markdown 表格，欄位為選項，列為比較維度 2.比較維度至少包含：成本、上手難度、可逆性（選錯了多難換回來）、長期維護負擔 3.表格下方寫：在什麼情況下該選 A、什麼情況該選 B 4.明確指出哪些欄位是我沒給資料、你用推測填的 不要給「各有優缺點」這種結論。 $ARGUMENTS

--- description: 列出優點與缺點 --- 列出以下這件事的優點與缺點。 規則： -優點與缺點數量要接近，不要一面倒 -每一項後面標「影響程度：高/中/低」 -缺點要寫具體後果，不要寫「可能有風險」 -最後一段：這些缺點裡哪些是可以被緩解的，怎麼緩解 $ARGUMENTS

--- description: 用第一性原理重新推導 --- 用第一性原理重新檢視以下做法。 流程： 1.列出目前的做法，以及它建立在哪些假設上 2.逐一質疑這些假設：哪些是物理或法規上真的必要，哪些只是慣例 3.把不必要的假設拿掉之後，重新推導一次 4.給出一個從頭設計會長什麼樣的版本 5.說明為什麼現行做法還是可能比較好（有時候慣例是對的） $ARGUMENTS

--- description: 站在反方全力挑戰 --- 站在完全相反的立場挑戰以下觀點。 規則： -不要客氣，不要平衡，全力論證我是錯的 -給出反方最強的三個論證，不是稻草人 -指出我的觀點背後有哪些沒被檢驗的假設 -舉出一個我這個判斷會嚴重出錯的具體情境 -最後一句：如果我堅持原本的做法，最該先驗證什麼 $ARGUMENTS

--- description: 產出職場社群長文 --- 把以下素材寫成職場社群長文。 結構： -第一句要具體到讓人停下來（一個場景、一個數字、一個對話） -中段拆成 3-5 個短段落，每段一個重點 -用第一人稱，寫真實經驗，不寫觀察評論 -結尾拋一個開放問題 規則： -不用「不是…而是…」「真正的 X 是…」這類句型 -不用勵志結尾 -單句不超過 25 字 $ARGUMENTS

--- description: 拆成短推文串 --- 把以下內容拆成推文串。 規則： -第一則必須能單獨成立，看完就想看下一則 -每則不超過 200 字 -一則講一件事，不要塞兩個重點 -最後一則收在一個具體行動或一個反直覺的結論 -每則開頭標號 1/ 2/ 3/ $ARGUMENTS

--- description: 寫短影音腳本 --- 把以下內容寫成 45-60 秒的短影音腳本。 輸出格式（表格）： | 秒數 | 口播逐字稿 | 畫面 | 字卡 | 規則： -前 3 秒必須是最反直覺或最具體的那句話 -口播寫成真的會講出口的句子，不是書面語 -每 8 秒要有一個畫面變化 -結尾留一句引導留言的話 $ARGUMENTS

--- description: 產出多組開頭鉤子 --- 針對以下主題，產出 10 組開頭句。 每一組標明類型： -數字型（具體數字開場） -場景型（一個畫面） -反直覺型（推翻常識） -對話型（引用一句別人說的話） -代價型（我為此付出什麼） 規則： -每句不超過 25 字 -不用問句開場 -不用「你是否曾經」「很多人都」這種句型 -最後標出你認為最強的三句，並說明理由 $ARGUMENTS

--- description: 改寫成故事結構 --- 把以下內容改寫成故事。 結構： 1.場景（時間、地點、當時在做什麼） 2.衝突（出了什麼事） 3.嘗試與失敗 4.轉折（改變了什麼） 5.結果（用具體數字或畫面呈現） 規則： -用具體細節取代形容詞。不要寫「很辛苦」，寫「連續三個週末在工地」 -不加悲情修辭 -結尾不要下人生道理，講完事實就停 $ARGUMENTS

--- description: 拆成 IG 輪播結構 --- 把以下內容拆成 IG 輪播。 每一張輸出： -張次與角色（封面／內容／總結／CTA） -主標題（10 字以內） -副標（16 字以內） -內文（2-4 行，每行 20 字以內） 規則： -總張數 8-10 -封面標題要有數字或身分 -每一張都要有讓人想滑下一張的理由 -最後一張放留言關鍵字引導 $ARGUMENTS

--- description: 產出多組標題選項 --- 針對以下內容產出 12 組標題。 分四種方向，每種三個： -直述型（清楚說明內容是什麼） -數字型 -好奇型（留一個資訊缺口） -利益型（讀者會得到什麼） 規則： -每個標題 20 字以內 -不做標題殺人，內容給不出的不要寫在標題 -最後標出你推薦哪一個，理由一句話 $ARGUMENTS

--- description: 寫社群貼文文案 --- 針對以下內容寫社群貼文文案。 結構： -開頭一句有畫面感的陳述（不用問句） -中間 2-4 行補充或觀點 -一句行動引導 -8-12 個 hashtag，分兩行 規則： -150-250 字 -口語，直接，不說教 -不用勵志收尾 -不用「這讓我想到」「值得注意的是」這類過渡句 $ARGUMENTS

--- description: 改寫成高互動版本 --- 改寫以下內容，提高留言與分享的機率。 要做的事： 1.前三秒或第一句加強到讓人停下來 2.中段埋一個會讓人想反駁或補充的觀點 3.結尾放一個低門檻的互動點（選 A 還是 B、留一個關鍵字） 4.找出原文哪一句最有傳播力，把它獨立出來當主軸 不要用煽動、對立、或誇大的手法。互動要來自內容本身。 $ARGUMENTS

--- description: 改寫成專業可信的版本 --- 把以下內容改寫成專業版本。 要求： -每個主張後面要有理由或依據 -模糊的形容改成具體數字或條件（給不出數字就寫「視 X 而定」） -移除誇飾與絕對化用語（最好、唯一、保證） -主動標出這個說法的適用範圍與例外 保持可讀性，不要變成公文。 $ARGUMENTS 分類 04｜用人與招募 這一類是我自己重寫過的。 網路上流傳的版本是寫給求職者的：改履歷、談薪水、要內推。我這邊全部翻到老闆這一端。一百多個人的公司，人的事情比案子的事情多。 提醒：這一類會處理到求職者與員工的個人資料。丟進 AI 之前請先去識別化，姓名、電話、身分證字號、地址都拿掉。這是法遵問題，不是效率問題。

--- description: 撰寫職缺說明 --- 根據以下資訊撰寫職缺說明。 結構： -職稱 -這個職位存在的原因（解決公司什麼問題） -前三個月要交出什麼成果 -日常工作內容（具體到動作，不寫「協助相關事務」） -必要條件與加分條件分開列 -誰不適合這個職位 規則： -不寫「抗壓性強」「主動積極」這類無法驗證的條件 -薪資範圍如果我沒給，標「待填」，不要編 $ARGUMENTS

--- description: 履歷快篩與提問建議 --- 針對以下履歷做快速評估。 輸出： 1.三句話總結這個人做過什麼 2.與職缺的匹配度：高／中／低，一句話理由 3.值得追問的三個點（經歷中含糊或跳躍的地方） 4.明顯的紅旗（頻繁短期跳槽、時間空白、職稱與內容不符） 5.面試時該驗證的一個核心能力 不要做人格評價，只根據書面內容判斷。 $ARGUMENTS

--- description: 產出面試題目與判準 --- 針對以下職位設計面試題目。 產出 8 題，分三類： -情境題（給一個真實會遇到的狀況，問他怎麼處理） -追問題（針對履歷上的經歷深挖） -判斷題（沒有標準答案，看他的取捨邏輯） 每一題附： -好的回答長什麼樣 -差的回答長什麼樣 -這題在測什麼 不要出「你的優缺點是什麼」這類無效問題。 $ARGUMENTS

--- description: 模擬面試對答演練 --- 扮演以下職位的應徵者，跟我進行模擬面試。 規則： -你只回答，不要跳出角色給建議 -回答要真實，包含含糊、迴避、誇大這些真人會有的反應 -我說「結束」的時候，才跳出角色，針對我的提問技巧給回饋： 哪些問題問得好、哪些是無效問題、我漏問了什麼 職位與背景：$ARGUMENTS

--- description: 擬人資溝通訊息 --- 針對以下情境擬一份人資溝通訊息。 要求： -開頭直接講結論，不鋪陳 -理由具體但不涉及可能構成歧視的因素 -不給假希望，也不把話說死 -語氣尊重，不用官腔 -100-200 字 同時輸出：這封訊息可能引發的對方反應，以及該怎麼回。 $ARGUMENTS

--- description: 撰寫錄取通知 --- 根據以下條件撰寫錄取通知。 必須明確寫出： -職稱與直屬主管 -薪資結構（本薪、獎金計算方式、發放時點） -試用期長度與評核方式 -到職日與報到需準備的文件 -回覆期限 規則： -任何我沒提供的數字標「待填」，不要編 -語氣正式但不冰冷 -最後提醒我：這份通知還缺哪些應該補上的條款 $ARGUMENTS

--- description: 設計新人上手流程 --- 針對以下職位設計前 30 天的上手流程。 分三段： -第 1-7 天：認識環境與工具，目標是能獨立完成一件小事 -第 8-14 天：跟著做，目標是理解完整流程 -第 15-30 天：獨立負責，目標是交出第一個成果 每一段列出： -要學會的具體事項 -由誰帶 -檢核方式（怎麼確認他真的會了） 最後列出：這個職位新人最常在第幾天卡住、卡在什麼。 $ARGUMENTS

--- description: 分析薪資帶設計 --- 針對以下職位分析薪資設計。 輸出： 1.這個職位的薪資該由哪些要素決定（經驗、證照、產值、管理幅度） 2.建議的薪資帶結構：起薪、中位、上限，以及各自對應什麼能力層級 3.固定與變動的比例建議，以及理由 4.調薪的觸發條件 5.這樣設計會對現有團隊產生什麼影響 如果需要市場行情數據，明確告訴我要去哪裡查，不要憑印象給數字。 $ARGUMENTS

--- description: 撰寫績效回饋 --- 根據以下事實撰寫績效回饋。 結構： -這一期做得好的：每一項綁一個具體事件或數字 -需要改善的：每一項綁具體事件，並寫出期待的樣子 -下一期的三個目標，每個要可衡量 -公司這邊會提供什麼支援 規則： -不做人格描述（「態度不好」「不夠積極」），只寫行為與結果 -不用三明治法把重點包糊掉，該講的直接講 -每一句都要是他聽完知道明天該怎麼做的 $ARGUMENTS

--- description: 盤點團隊職能缺口 --- 針對以下團隊與目標，盤點職能缺口。 輸出： 1.達成目標需要哪些能力（拆到可訓練的顆粒度） 2.目前團隊具備哪些、缺哪些 3.每個缺口的補法：內部訓練／外部招募／外包，並說明理由 4.補起來的預估時間與成本量級 5.哪一個缺口不補會直接卡死目標 $ARGUMENTS 分類 05｜營運與管理 這八個是我自己補的，原始清單裡沒有。 因為那份清單是寫給個人工作者的。我要管的是流程跟人，不是我自己的產出。

--- description: 撰寫標準作業程序 --- 把以下流程寫成 SOP 文件。 結構： -適用範圍與啟動時機 -角色與權責（誰做、誰核、誰知會） -逐步操作，每步標明：動作、使用工具、輸出物、耗時 -判斷節點：遇到 X 就走 A 路徑，遇到 Y 就走 B 路徑 -例外處理與升級規則（什麼情況要往上報） -相關表單與文件 假設執行者是剛到職一個月的員工。 $ARGUMENTS

--- description: 整理會議紀錄與待辦 --- 把以下會議內容整理成紀錄。 輸出三個區塊： **決議事項** 每一條寫成一句完整的決定。 **待辦** | 事項 | 負責人 | 期限 | 產出物 | 負責人或期限沒被指定的，標「未指定」並列在最後提醒我補。 **未決事項** 還沒有結論的爭議點，以及卡在什麼地方。 規則： -不要記流水帳，沒有結論的閒聊不要寫進去 -用中性語言，不記錄誰跟誰意見不合 $ARGUMENTS

--- description: 拆解成可交辦的任務 --- 把以下工作拆成可以分派出去的任務。 每個任務輸出： -任務描述（一句話，動詞開頭） -需要什麼能力層級（新人可做／需要經驗／必須主管） -預估工時 -交付標準（怎麼算完成） -前置依賴 最後列出： -哪些任務可以並行 -哪一件事只有我能做，不能交辦，以及為什麼 $ARGUMENTS

--- description: 設計可量化的績效指標 --- 針對以下目標設計指標。 每個指標包含： -名稱與定義（算式寫清楚） -資料從哪裡來、多久看一次 -目標值與底線值 -這個指標會誘發什麼行為（好的與壞的都要寫） 規則： -指標控制在 5 個以內 -每個指標要能被單一團隊影響，不要訂連他們自己都控制不了的 -最後獨立一段：這組指標最可能被怎麼鑽漏洞 $ARGUMENTS

--- description: 擬廠商溝通訊息 --- 針對以下情境擬一封給廠商的訊息。 要求： -第一段就講清楚要什麼、期限是什麼 -引用具體依據（合約條款、先前的往來、實際交期紀錄） -語氣專業但態度明確，不軟不硬 -給對方一個明確的回覆動作與時限 同時輸出： -對方最可能怎麼回 -如果對方拖延，下一步該怎麼做 $ARGUMENTS

--- description: 盤點風險與應對 --- 盤點以下事項的風險。 輸出表格： | 風險 | 觸發情境 | 發生機率 | 影響程度 | 早期徵兆 | 應對做法 | 規則： -至少列 8 項 -「早期徵兆」要具體到可以被觀察到，不要寫「情況變差」 -依「機率 × 影響」排序 -最後單獨標出：哪一個風險發生了會直接讓整件事停擺 $ARGUMENTS

--- description: 整理成週報 --- 把以下資料整理成週報。 固定結構： 1.本週結論（三句話以內，老闆只看這段） 2.數字：本週 vs 上週 vs 目標，變化超過 10% 的標出來 3.完成事項（只列有產出的） 4.卡住的事：卡在什麼、需要什麼支援、誰能解 5.下週重點（三項以內） 規則： -不寫「持續進行中」這種無資訊的句子 -沒有數據的部分標「無數據」，不要用形容詞代替 $ARGUMENTS

--- description: 撰寫交接文件 --- 根據以下內容撰寫交接文件。 必須涵蓋： -負責的業務範圍與例行工作（含頻率） -進行中的案子：現況、下一步、關鍵聯絡人 -需要移交的帳號、權限、檔案位置 -對外窗口：對方是誰、往來習慣、目前的關係狀態 -尚未解決的問題與坑 -只有他知道的事（口頭承諾、非正式默契、特殊處理慣例） 最後一段：接手的人第一週該優先確認哪三件事。 $ARGUMENTS 分類 06｜決策與成本 這八個我用最兇。 我做的每一個判斷最後都會回到同一件事：這樣划不划算。

--- description: 估算成本結構 --- 估算以下這件事的成本。 分四類拆解： 1.直接成本（材料、人力、外包） 2.間接成本（管理、場地、工具、行政） 3.時間成本（誰的多少小時，換算成金額） 4.隱藏成本（學習曲線、錯誤重工、機會成本、後續維護） 規則： -沒有我提供數據的部分，標「需要你提供 X」，不要編數字 -給區間不給單點，並說明區間上下限的假設 -最後：這筆錢裡哪一項最容易被低估 $ARGUMENTS

--- description: 拆解報價結構 --- 拆解以下報價。 輸出： 1.各項目佔總價的比例 2.哪些項目明顯偏高或偏低，理由是什麼 3.哪些項目定義模糊，可能之後追加（「一式」「視現場狀況」這類） 4.缺漏的項目：這類工程通常會有但這份沒列到的 5.可以議價的空間在哪一項，怎麼談 如果是我要出的報價，額外列出：哪些項目該寫更清楚以免日後爭議。 $ARGUMENTS

--- description: 分析投入產出 --- 分析以下投資的投入產出。 輸出： 1.總投入（含首次與持續投入，分開列） 2.預期回報：分「省下的成本」與「多賺的收入」兩類 3.回本時間點的估算，以及算式 4.回報要成立必須滿足哪些前提 5.悲觀情境：如果只達成一半，還划算嗎 規則： -所有數字標出是我給的還是你推估的 -不要為了讓結論好看而樂觀估計 $ARGUMENTS

--- description: 分析取捨與代價 --- 分析以下選擇的取捨。 針對每個選項寫出： -選了它，我得到什麼 -選了它，我放棄什麼（要具體，不要寫「彈性」這種空話） -這個決定的可逆性：選錯了要多久、多少錢才能改回來 -三年後回頭看，最可能後悔哪一點 最後：這個決定該現在做，還是可以先做小規模測試再決定。 $ARGUMENTS

--- description: 推演最壞情況 --- 推演以下這件事的最壞情況。 輸出： 1.最壞的具體場景（寫成一個會發生的故事，不是抽象描述） 2.導致這個結果的關鍵環節是哪一步 3.財務上的最大損失估算 4.除了錢以外會損失什麼（人、客戶關係、時間、商譽） 5.有沒有辦法在事前設一個停損點 6.如果真的發生了，第一週要做的三件事 不要安慰我，也不要誇大。 $ARGUMENTS

--- description: 排出優先順序 --- 把以下事項排出優先順序。 排序邏輯依序考慮： 1.不做會造成損失的（防守型）優先於會帶來收益的（進攻型） 2.有時間窗的優先於隨時可做的 3.卡住別人的優先於只影響自己的 4.高影響低成本的優先 輸出： -排序後的清單，每項一句話說明為什麼排這個位置 -「現在不做」的清單：哪些可以延後、哪些可以直接不做 -這一批事情裡，做完哪一件會讓其他幾件變簡單 $ARGUMENTS

--- description: 判斷是否該停損 --- 判斷以下這件事該不該停。 流程： 1.把已投入的成本先列出來，然後明確標註：這些是沉沒成本，不納入判斷 2.只看未來：再投入多少、能拿回多少、機率多高 3.如果現在停，損失是什麼、能回收什麼 4.如果繼續，需要滿足哪些條件才會轉正 5.給一個明確的判斷：停、繼續、或設一個檢核點再決定 6.如果是設檢核點，寫出檢核的時間與具體標準 不要因為投入很多就傾向繼續。 $ARGUMENTS

--- description: 給出明確決策建議 --- 針對以下問題給我一個明確的決定。 規則： -必須選一個，不准回答「視情況而定」或「各有優缺點」 -先給結論，一句話 -然後給三個理由，依重要性排序 -然後誠實寫出：這個建議最大的弱點是什麼 -最後給一個反悔條件：出現什麼訊號時我該推翻這個決定 如果資訊真的不足以判斷，明確列出還缺哪三項資訊，以及要去哪裡拿。 $ARGUMENTS 六間公司怎麼分資料夾 指令建好只是第一步。一百多個人在用，管理方式比指令本身重要。 我的做法： ~/.claude/commands/ ← 我個人的，跨所有公司 ├── brief.md ├── critic.md ├── cost.md ├── decide.md └── priority.md /工作/設計公司/.claude/commands/ ← 只有設計部看得到 ├── quote.md ← 內含我們的計價規則 ├── proposal.md └── change-order.md /工作/工廠/.claude/commands/ ├── check.md ├── yield.md └── vendor-cn.md /工作/醫美/.claude/commands/ ├── consult.md └── compliance.md ← 廣告用詞法規檢查 三個原則： 一、產業知識用 @ 引用，不要寫死在指令裡 錯的做法：把計價規則直接寫進 quote.md。規則改了要改十個檔案。 對的做法： 對照 @docs/計價規則.md 拆解以下報價： $ARGUMENTS 規則放在 docs/計價規則.md，改一個檔，所有引用它的指令同步更新。 二、專案層指令跟著 repo 走 .claude/commands/ 放在專案資料夾裡，會跟著版控一起交付。新人 clone 下來就有全套指令，不用另外教。 三、有副作用的指令加 disable-model-invocation: true 會發信、會刪檔、會提交的指令，設成只有人手動打才會觸發，避免 Claude 自己判斷要用而誤觸。 新人第一天只給這六個 我試過一次給全部 56 個。結果是沒有人打開。 現在的做法是：新人第一天只裝六個。 指令 為什麼是這六個

mkdir -p .claude/skills/quote mv .claude/commands/quote.md .claude/skills/quote/SKILL.md # 然後把範本檔放進 .claude/skills/quote/ 裡