AI 不會拒絕你。 你說要加功能，它就加——不管那個功能會不會把專案帶偏。 這個 skill 補的是那個缺席的環節：在需求進入開發之前，先問「這該做嗎」。
一個 Claude Code skill。它讀懂既有專案、承載你定下的紅線， 當新需求偏離時攔下來提醒——但你堅持，它就放行。
English ｜ 安裝 ｜ 三條鐵律 ｜ 綱領系統 ｜ 為什麼
AI 開發工具的預設行為是服從。你給需求，它拆規格、寫 code、跑測試，不停不問。
這在執行階段是優點，在決定要不要做的階段是災難：
- 客戶說「順便加個匯入功能吧」→ AI 開始寫，沒人問這是不是這版該做的
- 三個月後回頭看，專案長成一個誰都說不清楚邊界在哪的東西
- 而每一步都是你自己同意的——因為沒有任何一步有人攔你
問題不在 AI 太笨，在沒有人扮演守門員。而守門員這個角色，恰恰不能由 AI 自己兼任—— 它會變成無限追問，或者更糟，變成 AI 用「我覺得需求不夠清楚」當藉口。
這三條是這個 skill 的全部重點。違反任何一條，它就失去存在意義。
方向由你定。 這個 skill 只接住、記下、守住，不產生方向、不憑主觀判斷。
「不建議」必須引用你自己寫下的綱領條目，否則不得攔截。
這條防的是 AI 用自己的品味當標準。它沒有資格判斷你的專案該往哪走—— 它只有資格提醒你「這件事跟你三週前寫下的那條紅線衝突」。
你堅持要做就放行。 把關只防「不清楚／偏離的需求溜進去害下游失焦」，最終決定權在你。
預設語氣是「你大概漏給了背景，補一下？」而不是「你錯了」。 多數時候偏離是因為 AI 不知道你剛跟客戶談了什麼——而不是因為你判斷失誤。
把「專案現狀 ＋ 綱領 ＋ 需求」攤清楚讓你判斷，然後退場。
⚠️ 禁止 AI 自評需求清晰度——那只會變成過度勤奮的藉口。
這條是踩過坑寫的。一旦允許 AI 打分，它就會發現「需求還不夠清楚」是一個永遠成立的判斷， 然後你會花整個下午回答問題，而不是寫 code。
把關的依據全部來自綱領。綱領是養出來的——從模糊開始，靠每次「偏離 → 溝通 → 補一條」長厚， 不需要一開始就完美。
約束 = 「具體不做什麼」的紅線（Non-Goals），不是模糊的「規則／限制」。
範例：「不做 OTA 訂單匯入」「不做派單系統」「別為滿足客戶無限擴充」。
為什麼是 Non-Goals 而不是 Goals：
「明確不做什麼」比「要做什麼」更擋得住偏離——前者有限、鋒利；後者無限、模糊。
你列不完「這個專案要做的所有事」，但你列得完「這一版明確不碰的五件事」。 而偏離永遠是從那五件事之一開始的。
平時把關只掃 INDEX.md；要深究某條紅線，才細讀第二層。這是為了不讓守門本身變成負擔。
doc/plan-scope/
├── INDEX.md ← 第一層：每次都讀
│ • 核心目的（一句話 ＋ 指向 charter.md）
│ • 約束／紅線清單（每條一行） ★ 比目的更鋒利
│ • 戰略目標清單（每個一行）
│ • 完成存檔清單
│
└── 第二層：按需細讀
├── charter.md ← 核心目的全文
├── constraints.md ← 約束全文（一行講得清就不必有此檔）
├── goals/<slug>.md ← 某戰略目標 ＋ 執行策略
└── archive/<slug>.md ← 已達成目標的存檔
需求（模糊也可以）
│
▼
┌───────────────────────┐
│ 對照 INDEX 的紅線 │
└───────────┬───────────┘
│
撞到紅線／偏離核心目的／目標未提及？
│
┌─────────────────┴─────────────────┐
│ 是 │ 否
▼ ▼
攔下，引用具體條目 放行
「你大概漏給了背景？」
│
├─ 補齊背景後對上綱領 ──────────▶ 放行
├─ 溝通出新共識 → 記進綱領 ─────▶ 放行（綱領長厚）
└─ 你堅持 ─────────────────────▶ 放行（鐵律 2）
入口不要求需求明確——模糊是常態。 它會只精準讀跟這個需求相關的那幾塊現狀來顯影模糊目的， 而不是把整個 codebase 讀一遍。
plan-scope 守的是需求範圍 / 該不該做，不是「邊界選項怎麼選」——後者是下游的活。
放行的需求會整理成交棒檔（純需求、不含 code、純文字）：
| 檔案 | 內容 |
|---|---|
01_訪談稿.md |
乾淨敘事：點名角色、每個功能講完整正常流程（前置→觸發→步驟→結束） |
02_明確不做.md |
把紅線 1:1 抄成「這版不做 X，因為……」 |
03_樣本資料.md（選配） |
檔頭須明標「參考樣本，非功能需求」 |
charter 紅線 → 02_明確不做 → 下游的 NG-xxx → 圍欄
漏抄的紅線，會在下游復活成功能。 這是最常見的失敗模式： 你在綱領裡明明寫了「不做派單」，但交棒時沒抄過去，下游的需求分析看不到它， 於是「派單」作為一個合理的延伸功能被重新發明出來。
其他兩條規則：
- 不自動串下游——產出交棒檔就停，是否接著跑由你決定
- Excel 不可直接丟進 input——先匯出 CSV 或 Markdown 表格，否則掃描器讀到二進位亂碼
git clone https://github.com/youllook/plan-scope.git ~/.claude/skills/plan-scopeWindows (PowerShell)：
git clone https://github.com/youllook/plan-scope.git "$env:USERPROFILE\.claude\skills\plan-scope"單一 SKILL.md，無相依套件。
/plan-scope
或「當我的守門員」「這需求該做嗎」「守一下方向」。
第一次跑會走冷啟動：讀懂專案現狀，然後問你核心目的與「具體不做什麼」，建立 INDEX.md。
之後每次就只是對照。
A scope gatekeeper for agentic coding. AI coding tools default to compliance — you ask for a feature, they build it, no one asks whether it belongs. This skill supplies the missing step: before a requirement enters development, ask whether it should.
Three rules, and they are the whole point:
- Execute the charter, don't write it. Direction is yours. The skill only holds and enforces. Any objection must quote a constraint you wrote — it may not invoke its own taste.
- Blocking is not vetoing. If you insist, it passes. Default tone is "you probably left out some context — fill me in?", not "you're wrong."
- Present, don't score.
⚠️ The AI is forbidden from rating requirement clarity — that only becomes an excuse for infinite diligence.
The core idea is that constraints are Non-Goals, not vague "rules":
"Explicitly not doing X" holds a line better than "we want to build Y" — the former is finite and sharp; the latter is infinite and vague.
You can't enumerate everything a project should do, but you can enumerate the five things this version explicitly won't touch. Drift always starts with one of those five.
Watch the waterway: charter red line → handoff doc → downstream non-goals → guardrail.
A red line you forget to copy forward gets reinvented downstream as a feature.
The skill body is in Traditional Chinese. Install by cloning into ~/.claude/skills/.
- wrap-up — 收工協議：壓縮記憶、清理分支、發布驗證、寫明日第一步
- excuse-master — 向上溝通評分系統
- dev-os — 多 AI 協同開發，GitHub Issue 當交接介面
MIT