下午要送 PR 之前，你又打了一次那段熟到不行的提示：「幫我審一下這個 PR 的邊界條件、有沒有資安問題、測試夠不夠」。昨天打過、上禮拜也打過，每次措辭都差一點，品質就跟著飄一點。

commit 也是。今天心血來潮把 scope 寫好、加了 conventional 格式，明天趕時間就退化成一句「fix bug」。修 bug 更慘——你明明知道該先寫一個能重現的 failing test 再動手，但十次有六次直接改 code，測試事後補（或根本沒補）。

問題不在你不懂這些紀律，在於紀律放在腦袋裡，每次都要靠自制力重新執行一遍。

你可能試過半套解法：把常用提示存成備忘錄、貼到一個 snippets app、甚至塞進 Raycast。能省幾秒打字，但治不了根——因為每次貼出去的還是「大概那個意思」的版本，不是同一個版本。

agent-rules 切進來的，正是這一步。它的主張很直接：prompt 不該每次重打，prompt 該被當成設定檔。 把那段 PR review 的提示寫死成一個檔案，丟進 ~/.claude/commands/，之後在 Claude Code 裡打 /pr-review 就跑——跟你打 /commit、/bug-fix 一樣，跟 Linux command 同一個直覺。

5.7k stars / 514 forks，是目前 Claude Code 規則集合裡名氣最大的之一。作者 Peter Steinberger 是 PSPDFKit 創辦人，習慣把工程紀律寫死成可執行的東西。這個 repo 把工程師日常反覆下的提示，整理成 22 個 markdown 檔，把「我懂這個道理」變成「我每次都會做」。

倉庫結構：三層各自負責一件事

整個 repo 設計成三層，各做不同等級的事：

層級 用途 安裝位置
project-rules/ 22 個可重用的 slash command（commit / bug-fix / pr-review 等） ~/.claude/commands/ 或 .cursor/rules/
global-rules/ 帳號層級設定：MCP server 安裝腳本、issue 模板、terminal title 工具 ~/.claude/CLAUDE.md、shell rc
docs/ Swift / Apple 領域的大型參考文件（appkit / swiftui / uikit 各百萬字） 按需 import

核心是 project-rules/，22 個 .mdc 檔撐起整個工作流體驗。

為什麼用 .mdc 副檔名（小細節，但很聰明）

.mdc 本來是 Cursor 的 rules 格式：純 markdown 加 YAML frontmatter，可以宣告 description、globs、alwaysApply：

1
2
3
4
5
---
description: Clear, one-line description of what the rule enforces
globs: path/to/files/*.ext, other/path/**/*
alwaysApply: false
---

Claude Code 沒有這個概念，但它把 .mdc 當普通 markdown 讀，所以同一份檔案可以同時餵給 Cursor 跟 Claude Code。跨工具兼容的第一步不是寫適配器，是選對副檔名——這個觀察套到自己的規則庫上，可以省掉很多重複維護。

22 個指令，挑四類有代表性的看

Git & GitHub

指令 用途
/commit 完整版：跑 pre-commit checks、偵測 commit type、用 emoji + conventional 格式產出訊息、建議拆 commit
/commit-fast 快速版：生成 3 個訊息候選並自動採用第一個
/bug-fix 全流程：建 issue → 開 branch → 寫 failing test → 修 → push → 開 PR（含 Fixes #N）
/pr-review 6 種 persona 同時審：PM / Dev / QA / Security / DevOps / UX
/analyze-issue 用 gh issue view 抓 issue，輸出 10 段技術 spec

Code Quality

指令 用途
/check 跑 quality gate。明文禁止 commit、禁止改版號，純驗證
/clean 跑 formatter + type checker 修到全綠
/code-analysis 6 種分析菜單：knowledge graph / quality / performance / security / architecture / coverage

Development Workflow

指令 用途
/implement-task 5 階段方法論：think strategy → evaluate → tradeoffs → implement → checklist
/context-prime 讀 README、CLAUDE.md、git ls-files，建立對陌生專案的初步理解
/five Five Whys 根因分析：鏈式追問五次直到 root cause
/mermaid 從 SQL / source code 抽實體與關係，輸出 mermaid 圖並用 mmdc 驗證

Meta（規則自己進化）

指令 用途
/create-command 用 agent 幫你寫新的 slash command（meta-bootstrap）
/continuous-improvement 觀察 codebase 的 pattern，某個模式出現 3 次以上就建議寫成新規則
/cursor-rules-meta-guide 規範 .mdc 應該怎麼寫（含 DO / DON’T 對照範例）

安裝只要兩步：clone repo，跑 ./install-project-rules.sh。腳本做的事很單純——在 ~/.claude/CLAUDE.md 加一行 @<repo_path>/project-rules，靠 Claude Code 的 import 語法把 22 個 .mdc 全納入，裝完直接打 /commit、/bug-fix 就能用。給 Cursor 的話，把 project-rules/ 整個丟進專案的 .cursor/rules/ 就好。

真正值得偷的不是指令，是五個設計手法

讀完 22 個規則會發現，有些手法可以直接抄到自己的規則集裡。這部分比指令本身更有複利價值。

一、二段式工作流（完整版 vs 快速版）。 commit.mdc 跟 commit-fast.mdc 是同一件事的兩種精度。完整版做安全把關，快速版省掉互動直接出 3 個選一個。趕時間用 fast，要進 production 用完整版。這個 pattern 套自己的規則集很實用——/test-quick vs /test-thorough、/review-self vs /review-team。

二、多 persona 自我審查。 pr-review.mdc 用 6 個角色同時看一段 PR：PM 看需求、Dev 看架構、QA 看覆蓋率與邊界、Security 看漏洞、DevOps 看部署影響、UX 看體驗變化。比單一視角撈出更多問題。LLM 切換角色其實很順——給它一個角色加一個任務，它就用那個角色的優先序看事情，這個 prompt 結構連 persona 都不用改就能借。

三、把禁區寫在最前面、用大寫。 /check 規則開頭寫死 DO NOT commit. DO NOT change version numbers. Only verify.，mcp-inspector-debugging.mdc 開頭警告 DO NOT RUN BLOCKING TERMINAL COMMANDS。LLM 容易越界做副作用，最有效的方法就是在指令最前面用大寫寫死禁區。寫散文式的引導它會自己腦補；寫成大寫禁令它會當 hard constraint。

四、編號流程化。 所有規則都遵循固定骨架：Title → Usage → Process（編號步驟）→ Best Practices。寫散文 LLM 容易漏步驟，全拆成編號讓它逐條執行，準確度差很多。這也是寫文件的反直覺——人類讀者喜歡散文，但你的目標讀者是 LLM，LLM 喜歡編號。

五、self-evolving 機制。 continuous-improvement.mdc 規定：agent 在 codebase 觀察到某個 pattern 出現 3 次以上，就主動建議寫成新規則；/create-command 直接用 agent 幫你產生新指令骨架。把規則集當成「會自己長大的東西」設計，而不是寫完就鎖死的靜態文件——這個視角差異會決定你的規則庫一年後是更精煉還是更笨重。

實際跑起來，最有感的幾個場景：寫完功能打 /commit-fast 不用想訊息怎麼寫；碰到 bug 先打 /bug-fix 強制走「先寫 failing test」的 TDD 流程；送審前先用 /pr-review 讓六個 persona 自己打一遍；接手陌生專案打 /context-prime 拿結構摘要；業務丟個兩句話的 issue 連結，/analyze-issue 幫你產出 10 段技術規格。

動手前要知道的幾件事

最重要的一點：作者已停止積極維護。README 明示這是 2025 年中的舊作，新工作在 steipete/agent-scripts。當學習範本可以，當長期相依套件要三思。

其他踩坑點：不少規則是 macOS 專用（safari-automation、screenshot-automation、terminal-title-wrapper 在 Linux / Windows 跑不起來）；docs/ 的巨型檔案會吃 context（appkit.md 2.3MB、swiftui.md 1.8MB，直接 alwaysApply 會炸 context window，建議按需 import）；推薦的 MCP 生態（Peekaboo / Agent / Automator）都是作者自己發的 npm 套件，用前自己評估信任邊界；commit 規則內建 emoji，對禁用 emoji 的企業 convention 不友善；/check 假設專案有 npm run check，其他語言要自己改 fallback。

換句話說，把 Claude Code 或 Cursor 當主要 AI pair programmer、想找 .mdc 範本參考、或做 macOS/iOS/Swift 的人，這個 repo 撈得到東西。只用 GitHub Copilot、純 Linux/Windows、或期待持續更新的人，可以直接跳過去看 agent-scripts。

回到那段 PR review 提示

繞了一圈，回到開頭那個每天重打提示的場景。agent-rules 真正示範清楚的有兩件事：第一，prompt 一旦被當成設定檔，你就會開始把所有反覆寫的提示抽出來、放進版本控管、加上 review 流程——這個轉變對工程紀律的影響，比換一個更新的模型還大。第二，規則庫應該會自己長大，寫完就鎖死的只會越用越過時。

不用一次搬 22 個。挑你今天最常下的那一個 prompt——大概就是 commit 或 PR review——寫成一個 .mdc 丟進 ~/.claude/commands/，明天打那個 slash 試試看。比你以為的還順。

相關連結