# Project Guardrails

> 分析專案程式碼，找出「改 A 會壞 B」的連動禁區——高扇入模組、資料結構契約、部署設定、對外契約、演算法核心——經確認後寫入該專案的 CLAUDE.md。當使用者要建立 guardrails、問哪些程式碼不能亂動、哪些模組牽一髮動全身時觸發。也是 agentic-dev-loop Step 0 的前置階段。

- Skill: `goingli0324/project-guardrails` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add goingli0324/project-guardrails`
- Raw SKILL.md: https://api.skillmd.com/api/skills/goingli0324/project-guardrails/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: goingli0324 (https://skillmd.com/u/goingli0324)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/goingli0324/project-guardrails

---


# Project Guardrails(連動禁區建置)

分析專案程式碼,推導出改動風險最高的「連動禁區」,經使用者確認後寫入專案 CLAUDE.md。每個專案執行一次即可;專案架構大改後可重跑更新。

## 執行流程

### Step 1:判斷專案類型

讀取根目錄設定檔(package.json、firebase.json、.firebaserc、appsscript.json、
pom.xml / build.gradle、requirements.txt 等),判斷這是網頁前端、PWA、GAS 專案、
後端服務或混合型。後續檢查項目依類型調整。

### Step 2:推導連動禁區候選清單

逐類檢查,每項都要找到實際證據(檔案:行號),不可僅憑檔名推測:

1. **高扇入模組**:被 3 處以上呼叫的函式/模組/共用元件(用 grep 統計呼叫點)
2. **資料結構契約**:localStorage/IndexedDB 的 key 與 schema、資料庫 schema、
   GAS 專案的 Sheet 欄位結構與 Script Properties、API 的 request/response 格式
3. **部署設定**:.firebaserc、firebase.json、部署指令中的 --account 與 -P 旗標、
   GCP 設定、appsscript.json 權限範圍——此類一律列為禁區
4. **對外契約**:公開 URL 路由、Webhook 端點(如 LINE callback)、
   第三方服務串接點(Gemini API、LINE Messaging API 等)
5. **演算法核心**:計分、分級、判定等一旦改動就讓歷史資料不可比的邏輯
6. **PWA 基礎設施**(若適用):service worker 快取策略、manifest.json

### Step 3:確認後才寫入(硬性規定)

將推導結果整理成草稿,每項包含:模組名稱、實際檔案位置、被依賴方清單、
改動風險一句話。**完整呈現給使用者確認;在使用者明確回覆確認前,
不得寫入任何檔案。**

### Step 4:寫入專案 CLAUDE.md

- 已有 CLAUDE.md:將「## 連動禁區(修改前必讀)」段落附加於文末,
  不覆蓋、不改動任何既有內容;若已有同名段落,先呈現新舊差異讓使用者選擇
- 沒有 CLAUDE.md:建立之,內容為專案一句話簡介 + 連動禁區段落

### Step 5:回報

回報共列入幾項禁區,並明確指出哪幾項信心較低、建議使用者人工複核。
推導不到證據的項目寧可不列,也不要靠猜測充數——禁區寫錯方向比沒寫更危險。