把一條最佳實踐登記進 clade 的正確落點,或查新專案該套用哪些既有標準。Use when 使用者送 `\\bp`、說「這個記成最佳實踐」「這條規範收進 clade」,或問新專案該套哪些現成標準。NOT for 寫進 memory,NOT for 散播既有改動(走 clade-publish)。
Scanned 9/5/2026
Install to Claude Code
npx -y skills add Charles5277/nuxt-supabase-starter --skill bp --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Bp?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/charles5277-nuxt-supabase-starter)More formats (shields.io, HTML) on the badges page.
---
name: bp
description: "把一條最佳實踐登記進 clade 的正確落點,或查新專案該套用哪些既有標準。Use when 使用者送 `\\bp`、說「這個記成最佳實踐」「這條規範收進 clade」,或問新專案該套哪些現成標準。NOT for 寫進 memory,NOT for 散播既有改動(走 clade-publish)。"
license: MIT
metadata:
author: clade
version: "1.0"
permission_tier: draft
---
<!-- 🔒 LOCKED — managed by clade · auto-generated by sync-to-cursor; edit source in .claude/ then re-run sync -->
# bp — 最佳實踐落點路由
clade 有 7 種資產落點。**分類負擔歸本 skill,不歸使用者**——使用者只需要講出那條實踐是什麼,落點由這裡判、講出理由、等確認。
## Mode dispatch
| Mode | 觸發 | 用途 |
| --- | --- | --- |
| `record`(預設) | `\bp <一句話>`、「記成最佳實踐」 | 判落點 → 回報 → 等確認 → 落地 |
| `plan` | 「新專案該套哪些現成標準」 | 依 stack 列出該套用的既有 convention |
| `check` | `/bp check`、commit gate 0-F 呼叫 | 對 staged diff 比對既有資產,防重造輪子 |
---
## record
### Step 1 — 判定 session 位置
| 目前在 | 做法 |
| --- | --- |
| clade(`~/offline/clade`) | 直接往下走 |
| consumer | 這是 Direction B 跨界(consumer session → clade 改源頭 + 散播)。使用者送 `\bp` **就是**明確授權,往下走;落地後 MUST 回到原 consumer 並明示已回來 |
### Step 2 — 問三個問題
**MUST 自己先答一遍**,答不出來的才問使用者。目標是使用者回是非題,不是回「該放哪一層」。
| # | 問題 | 分支 |
| --- | --- | --- |
| Q1 | 誰需要知道? | 全 consumer → `rules/core/`/某類 stack → `rules/modules/<group>/<variant>/`/只有 clade → `.cursor/rules/local/`/**只有某一個 consumer → 該 consumer 自己的 `.cursor/rules/local/` 或 `tasks/lessons.md`,不進 clade** |
| Q2 | 何時需要知道? | 每個 session → always-load rule/編輯特定檔時 → 帶 `paths:` 的 conditional rule/做特定任務時 → skill/查得到就好 → `vendor/snippets/` 或 `docs/` |
| Q3 | 它是什麼形態? | 判準 → rule/操作步驟 → skill 或 snippet/可執行 → `vendor/scripts/`/成因與退場條件 → `docs/rule-rationale/`/失敗案例 → `docs/pitfalls/`/**有 variant 與成熟度 → `registry/conventions.json`** |
Q1 最後一支是**不收**的出口:`\bp` 送進來的實踐若只對一個 consumer 有效,落點在該 consumer 自家,不是 clade。證據只有一次 session 的觀察 → `tasks/lessons.md`;已演進成穩定規約 → 該 consumer `.cursor/rules/local/`。**NEVER** 因為使用者送了 `\bp` 就一定要在 clade 找一個落點塞進去。
Q3 最後一支最常被漏掉:**一條實踐若存在「推薦做法 vs 過渡做法」的分歧,它 MUST 進 `registry/conventions.json`**——那是唯一機讀的最佳實踐目錄,沒進去的條目 `plan` 與 `check` 兩個 mode 都抓不到,等於登記了卻不會被套用。
Q2 / Q3 判到 `docs/` 之後**還有一層**:`docs/` 有 13 個子目錄,落哪一個以 `docs/README.md` 為 SoT——它定義各子目錄的准入 predicate、三組易混淆目錄的判準與掃描面契約,設計上就是給本 skill 判落點用的。**判到 `docs/` 就 MUST 讀它**,**NEVER** 憑目錄名字猜,也 **NEVER** 把那些 predicate 複製進本檔(複本必漂移,正是該憲章 § 維護 要防的)。
完整 Q1×Q2×Q3 對照表、縱向下推三分法(留原處 / `docs/rule-rationale/` / 新建 conditional rule)、以及各落點的散播機制,見 `references/placement-routing.md`。**判不出來時 MUST 讀它**,不要憑印象猜。
### Step 3 — 回報,等確認
**MUST** 用這個形狀回報,然後停下:
```
落點:<具體檔案路徑>
理由:<一句話,對到 Q1/Q2/Q3 哪一支>
要動的檔:<逐條列,含既有檔的哪一節>
連帶:<要不要同時進 conventions.json / 補 audit signal / 補 pitfall>
```
**NEVER** 未經確認就寫入。這個 skill 存在的理由就是讓落點判斷可被當場推翻——自己落地就把可推翻性拿掉了。
### Step 4 — 落地
確認後才寫。寫完走 `/clade-publish`(**NEVER** 憑記憶重跑 publish 流程)。
新增 rule 或 skill 時連帶:
- 動 rule / SKILL / snippet 措辭前,先讀 `rules/core/rule-authoring.md` § 先分類失敗型態,再選形式
- 新 skill **MUST** 先寫 `evals/skills/<name>/cases.json` 再寫 SKILL.md(EDD)
- 新 audit script 先過 `propagate-maintenance-mode` 三問,並補 `registry/audits.json` entry
---
## plan
```bash
node ~/offline/clade/scripts/bp-scan.ts --plan --repo <目標 repo 絕對路徑>
# 尚無 hub.json(溝通期)時:
node ~/offline/clade/scripts/bp-scan.ts --plan --json --modules '<hub.json modules JSON>'
```
有 hub.json 就讀它的 `modules`;沒有就餵 `--modules`。再對 clade `registry/conventions.json` 輸出這個 stack 該套用的 convention、各自的 `rule_refs` / `snippet_refs` / `doc_ref`,與現況 adoption。plugin/rule/skill 清單不在這裡——那是 `projectionPlan({ cladeRoot, manifest })`。
**輸出是候選不是指令**:逐條跟使用者確認要不要套,**NEVER** 自行對 consumer 業務檔動手(per `clade-role-and-todo-discipline` § 反模式)。
## check
```bash
node ~/offline/clade/scripts/bp-scan.ts --changed-only
```
對 staged diff 比對既有資產索引。輸出分兩類,**判讀方式不同**:
| 類別 | 可靠度 | 怎麼處理 |
| --- | --- | --- |
| 未登記 / 無入向引用的新資產 | 機械精確 | 直接補登記或補引用 |
| 主題詞命中的既有條目 | 有偽陽性 | 人工看一眼「這條是不是已經涵蓋我要做的事」 |
**NEVER** 把第二類的命中講成「確定重複」——它是檢索提示,不是語意重複偵測。
---
## 守則
1. **NEVER 自行落地**。record mode 一律回報後等確認(Step 3)。
2. **NEVER 把該進 memory 的東西寫進 clade 源檔**。純個人偏好 / 純事實指針 / 無法歸進任何規約檔的碎片 → memory(且 MUST 先問過使用者)。反過來,可以變成 rule / cookbook / snippet 的東西 **NEVER** 塞進 memory。
3. **NEVER 只寫 rule 不接消費端**。新規約若沒有對應的 audit signal 或 gate,它只是一段沒人讀的文字;接不上消費端時要明講這條是純參考。
4. **clade 主線不替 consumer 排實作**。`plan` mode 的輸出是給 consumer 自家 session 用的候選清單,不是 clade 主線的待辦。
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!