Bp

---
name: bp
description: 把一條最佳實踐登記進 clade 的正確落點，或查新專案該套用哪些既有標準。Use when 使用者送 `\bp`、說「這個記成最佳實踐」「這條規範收進 clade」，或問新專案該套哪些現成標準。NOT for 寫進 memory，NOT for 散播既有改動（走 clade-publish）。
license: MIT
metadata:
  author: clade
  version: "1.0"
  clade:
    permission_tier: draft
---

<!-- clade-skill-scope: both -->

# 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 → clade 自己的 `.claude/rules/local/`（clade home 是 Claude session，這格是字面路徑不是投影）／**只有某一個 consumer → 該 consumer 自己的 `.clade/rules/` 或 `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 `.clade/rules/`。**NEVER** 因為使用者送了 `\bp` 就一定要在 clade 找一個落點塞進去。

Q3 最後一支最常被漏掉：**一條實踐若存在「推薦做法 vs 過渡做法」的分歧，它 MUST 進 `registry/conventions.json`**——那是唯一機讀的最佳實踐目錄，沒進去的條目 `plan` 與 `check` 兩個 mode 都抓不到，等於登記了卻不會被套用。

Q2 / Q3 判到 `docs/` 之後**還有一層**：落哪一個子目錄以 `docs/README.md` 為 SoT——它定義各子目錄的准入 predicate、三組易混淆目錄的判準與掃描面契約，設計上就是給本 skill 判落點用的。判到 `docs/` 就讀它，不憑目錄名字猜；也不把那些 predicate 複製進本檔（複本會漂移）。

完整 Q1×Q2×Q3 對照表、縱向下推三分法（留原處 / `docs/rule-rationale/` / 新建 conditional rule）、以及各落點的散播機制，見 `references/placement-routing.md`，判不出來時讀它。

### 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 主線的待辦。