gyf0311/lorekit/wiki-triage

wiki-triage

工作台淤积的定期清算。不挂定时任务，先生说才跑；AI 负责扫描与预判，裁决权永远在先生。

设计原因：入库门 = 先生的明确指令（契约红线），所以内容会合规地停在工作台。 本 skill 是反向流程——把账单递到先生面前，把"裁决 91 条"压缩成"对 4 组说是/否"。

When to trigger

• 先生说"整理一下工作台"、"清算工作台"、"工作台该清了"
• 先生问"工作台堆了什么"、"有什么该入库的"

不要触发：先生只是让你在工作台里找/放某个文件（那是普通文件操作）。

安全红线

1. 未勾选前不动任何文件——扫描与账单是只读动作。
2. 丢弃一律 lorekit trash，禁止 rm；破坏性动作不用 && 串联。
3. 原料/、知识库/ 不在扫描范围；本 skill 只处理 _工作台/ 与复盘候选。
4. 先生勾选"入库"= 明确入库指令，走完整 wiki-ingest 流程，不走捷径。

Step 1 — 确定性扫描（只读）

lorekit workbench report --json          # 默认：账龄 ≥45 天进候选；14 天内动过的目录整体跳过
lorekit workbench report --json --stale-days 30   # 先生指定阈值时调整

CLI 输出四组机械事实：candidates（路径/mtime/账龄/大小）、activeDirs（活跃项目， 已跳过）、excluded（固定排除层：_工作台/转写/、_工作台/日记收件/）、freshFiles。 注意语义：项目目录（用户自建文件夹）14 天内动过整目录跳过；标准过程桶 （收件/草稿/临时/待整理/下载）按单文件判账龄——桶里有新文件不影响老文件进候选。 不要自己写 find 片段重复这份逻辑；CLI 是候选生成的 SSOT。

另扫 fileback 候选堆积：读 输出/复盘/ 最近 2-3 份 synthesis 的 "Suggested fileback candidates" 小节，未消化的候选一并列入账单。

Step 2 — AI 预判分组

对扫描结果逐条判断，分四组（判断是 AI 做，裁决是先生做）：

拿不准的条目归入"归档候选"并注明存疑，绝不归入丢弃。

Step 3 — 账单（对话内呈现）

按组输出，每条一行：编号 | 文件 | 最后修改 | 一句话理由。 末尾给先生极简回复格式：全部同意 / 1,3 同意，2 归档改留着 / 只做归档组。

Step 4 — 按勾选执行

• 入库：完整走 wiki-ingest（mv 进 原料/ 定稿路径 → frontmatter 记

original_path → 编译/追加 知识库/ 页 → 反链 → lorekit ingest record）。

• 归档：mv 到 _归档/<项目名>/，保持原文件名；归档层可被

lorekit search --all 第二级召回检索到。

• 丢弃：逐条 lorekit trash，不批量串联。
• fileback 候选：勾选的走 wiki-fileback 追加 Timeline。

Step 5 — 收尾

1. lorekit sync（刷新索引 + MEMORY.md 统计 + doctor）
2. lorekit lint 确认无新增 hard issue（重点看 unresolved-source）
3. log.md 末尾追加一行：## [YYYY-MM-DD HH:mm] triage | 入库 N / 归档 N / 丢弃 N / 跳过 N
4. 向先生汇报执行结果与 Trash 可恢复提示