knowledge-groomlisted

# Knowledge Groom > **本地执行说明**：本 skill 标记 `disable-model-invocation`（防 agent 自发启动批量改库）——skill 工具加载会报 "not available for model invocation"，这是预期。用户明确要求 groom 时，agent 直接 `read` 本文件手动遵循流程即可，流程完整性不受影响；或用户输入 `/skill:knowledge-groom` 直接触发。 体系的演化引擎。不加控制的增长会摧毁检索效率——这个 skill 是知识库的"免疫系统 + 清道夫"。 ## 触发 手动运行，建议每周一次（连续四周无新 postmortem 则自动切双周）。 **触发场景区分（2026-09 明确）**： - **人工使用场景（默认周批）**：人通过 diagnose/to-postmortem 等沉淀的草稿——攒 inbox 到周批统一处理，人审 ~30s/条后升格提 PR（人的注意力是稀缺资源，批处理是预算分配， 原则九）； - **自动化 ingest 场景（可直接升格，不等周批）**：issue-ingest/S2 补 case 等自动化 链路产出的草稿——verification 链完整（upstream-fix-merged 等外部验证）+ agent 已过 语义校验 + pre-triage 判别完成，质量前提与人工场景不同，**产出后可直接走本流程升格 入库提 PR**（同 2026-W36 round2 全自动轮 22 case 升格先例）。前提：owner 已预授权该 自动化源（issue-ingest 链路本身即 owner 配置的持续管道，其产出视为预授权）。草稿头 注释带完整 pre-triage/verification 证据 → 复核确认而非重判。 ## 流程（一次 groom 产出一个变更摘要） 1. **intake 队列处理（升格的前置）**：处理 `postmortems/inbox/`（`/skill:to-postmortem` / `/skill:issue-ingest` 的产出都落这里）： - **节律**：单仓集中可周批；**分布式（成员本地 inbox，远程仓不存）在提交主仓时处理**——产出时已做 pre-triage（见下），groom 复核确认而非重判； - 逐条**预分诊**（agent 判断，给证据；当前不引入 embedding，论证见 docs/adr/0002——可选论证层）：`new_pattern` / `variant_of:<case-id>` / `covered_by:<case-id>` + 置信度。比对对象：命中 namespace + `common/` 的现有 case——用 `knowledge/_index.yaml` 按 symptoms/tags 定位候选，全量读比对 root_cause 与 fix。**draft 头注释已带 to-postmortem/issue-ingest 产出的分诊建议 → 复核证据是否成立，不重判**（建议与决定分离：判断在产出时做，groom 是审核者）； - 产出**批审清单**交 owner 处理（像清 PR inbox，~30 秒/条）： - `covered_by` → 建议关闭升格；postmortem 转正 `postmortems/YYYY-QN