workbuddy_skills/dsh-knowledge/SKILL.md

name, description, version, updated_at, last_change, agent_created

name	description	version	updated_at	last_change	agent_created
dsh-knowledge	DSH 平台**项目知识与架构资产**的维护总入口 —— 覆盖两半：① **知识库 / 文档维护与纠偏**（「文档与现状不符」「同一事实多处打架」「知识越积越碎」「AI 忘了某条规则」「要收敛或重构知识库结构」，以及定期体检；**说话能"这么多技能会不会挑不对 / 技能太多不好维护"时的技能集体检**）② **过程文档与架构定稿的分层机制**（要**写架构级设计**、要**把推演结论定稿**、要判断**某份文档该放过程还是定稿**、要查「**现在的架构到底是什么样**」、或发现**同一架构有多处互相矛盾的表述**）。核心 = 六层知识结构 L0–L5（含 **L0.5 架构定稿层**）＋ **分层判据（实体 vs 指针）** ＋ Lint 四件套（可接 CI）＋ 漂移处理 SOP 五步 ＋ **§9 技能集可用性体检（10 层取证法）** ＋ **§10 技能重组：千行技能拆分（主干 + references）** ＋ **两个目录的唯一分工判据** ＋ 定稿命名约定 ＋ 收敛五步 ＋ 冲突仲裁 ＋ 过时档案只加状态块 ＋ 定稿三道验收。判据实体在主干，**全文在 `references/`（2 档）**。	1.0.0	2026-09-28	【2026-09-28】**由 `dsh-knowledge-upkeep`（v1.0.0）＋ `dsh-architecture-lifecycle`（v1.0.0）合并而成**（两个原名退役）。按 `dsh-knowledge-upkeep §10`「主干 + 详情档」形态落地（**用本技能自己的方法重组自己**）：判据实体留主干、全文下沉 `references/`（**内容守恒：逐行 0 丢失**，含原 frontmatter 变更历史）。合并理由：两者是同一域的两半 —— 一个管「**知识怎么不变错**」，一个补「**L0.5 定稿层与收敛流程**」（前者的 §1.1 已显式引用后者）。另：`knowledge-upkeep` 的文档库版独有「🔵 作用域 ＋ 宿主落点对照（DSH ← WorkBuddy）」块，**已并入**（那张表是本技能跨宿主可用的关键）。⛔ 未删任何判据。	true

dsh-knowledge — 项目知识与架构资产维护

🔴 第 0 步：先分诊

情形	去哪
文档与现状不符 / 同一事实多处打架 / 知识越积越碎 / 定期体检	§1
「这么多技能会不会挑不对 / 技能太多不好维护」	§1 → 技能集体检（10 层）
某个技能已到千行级、加载太吃上下文	§1 → 技能重组（主干 + references）
写架构级设计 / 把推演结论定稿 / 判断某文档放过程还是定稿	§2
查「现在的架构到底是什么样」/ 发现架构表述互相矛盾	§2 → 冲突仲裁（以定稿为准）

---

1. 知识库 / 文档维护与纠偏

🔴 判据的对象是「description 的区分度」（技能按 description 匹配、按需加载）—— ⛔ 不是"正文写得好不好"。

六层知识结构 L0–L5（含 L0.5 架构定稿，见 §2）：L0 工作区规则 / L0.5 架构定稿 / L1 索引 / L2 状态层 / L3 交接与接续 / L4 过程档案 / L5 过程只增不改。

🔴 分层判据（决定"写实体还是留指针"）：

不看会导致「违规 / 事故」的 ⇒ 必须写实体；只让人"更慢更绕"的 ⇒ 给指针。 （对应本技能 §9 的口径：判据常驻 > 行数目标；判据密集的技能，≤350 行可能结构上不可达 ⇒ 达不到就如实报数字，⛔ 不许把硬规则降级成指针去凑行数。）

漂移处理 SOP 五步（发现 → 收敛）：定位 → 判新旧（分水岭） → 按结构重组 → 标回溯 → 标未决（🔴 红线：未决项必须显式）。

技能集可用性体检（10 层取证法） —— 每层一个脚本、落盘跑，⛔ 别用 python -c（含反引号会被 shell 吃掉 ⇒ 静默无效果）： 1 description 全量 ＋ 探针词重叠｜2 精确提取引号内触发短语（零重复＋零包含＝健康）｜3 真实说法→命中谁（期望技能不在命中集＝❌ 真缺陷，比"撞"严重）｜4 三处一致性/引用/版本/体量｜5 引用上下文逐条看（必须看原文语境，插件名/工作区名全是假阳性）｜6 自然说法覆盖率｜7 用历史会话原话做验证集（最强）｜8 盲区二分＋补漏词重跑｜9 用户明确定过的规则是否接得住（最容易漏、后果最重）｜10 frontmatter 结构校验（字段唯一性 ＋ 版本 x.y.z）。

🔴 两条最容易自我误导的：

• 判据漏词会伪装成"技能盲区" ⇒ 报盲区前必须先用目标技能的 description 原文核验一遍，确认不是自己的关键词表不全。⛔ 不许把"我判据里补的词"当成"技能已覆盖"。
• 不是所有"撞"都要消：良性撞（分工互补）多加载一个是好事 ⇒ ⛔ 不要为了"看起来干净"去削；只消恶性撞（撞了但偏向错误的一方）。修法＝补缺的说法 ＋ 给两边都加**「⚠️ 与对方的边界」（双向指认）**。

技能重组（千行拆分）：SKILL.md 留判据＋流程主干＋命令骨架，长表/案例/实测/历史 ⇒ references/<两位序号>-<主题>.md，原位只留一行指针。四条硬约束：① 内容守恒（可机械校验；⛔ 不许借机删任何判据/命令/事故事实）② 判据实体常驻 ③ 每档自包含（头写「覆盖哪些原章节＋原行段」）④ 三处同步 ＋ 登记跟改。 四项验收：① 守恒 ② 三处 md5 一致 ③ 原每一个标题在新结构可寻址 ④ frontmatter 唯一、version 递增。 🔴 下沉必带的副作用：正文里 见 §8 坑 9 / 见下表：X 这类编号引用会断头（实测一次抓到 5 处）⇒ 主干末节加一张「详情档 × 覆盖原章节 × 原行段」表定位。 🔴 落盘前必查两条：diff -rq 只比内容、查不出「脚本里写着旧工作区绝对路径」这种路径级引用；三处同步时服务器上也有根登记副本（README.md/INDEX.md），登记行按行首单元格匹配（⛔ 别用"技能名出现在这一行里"判命中）。

📂 全文 ⇒ references/00-知识库维护与纠偏.md（含 Lint 四件套细节、漂移 SOP 完整版、§8.6 注入预算（长文件后半段等于不存在）、§9 十层脚本清单与实测数据、§10 执行四步与 split_skill.py、§11 归档镜像治理、反例与自检清单） 📂 拆分器 ⇒ references/dsh-knowledge-upkeep/split_skill.py（--spec <json>，声明式规格＝纯搬运）

---

2. 过程文档与架构定稿的分层机制

🔴 两个目录、一个判据（本技能的核心）：过程答「怎么想的」／定稿答「该做成什么样」。

定稿命名约定：<对象>-<架构名>.md —— ⛔ 无编号前缀 · 一个目录装全部。 收敛五步（过程 → 定稿）：定位 → 判新旧 → 按架构重组 → 标回溯 → 标未决。 🔴 冲突仲裁：过程与定稿打架 ⇒ 以定稿为准，且必须写进两边。 🔴 过时档案只加「状态块」，⛔ 不改正文（改写历史记录＝造假）；且**⛔ 不要在两处同时改**。 定稿的三道验收：① 可独立读懂（不依赖过程档案）② 可照此施工 ③ 可回溯（能指回过程）。

📂 全文 ⇒ references/01-过程与定稿分层.md（含为什么需要它、唯一判据落到每一份文件、冲突仲裁细则、收敛五步的每一步、状态块纪律、定稿目录 README 要求、与既有技能的分工、自检、真实反例、一屏速查）

---

3. 详情档索引（跨档引用按此表定位）

档	覆盖的原技能	原章节
references/00-知识库维护与纠偏.md	dsh-knowledge-upkeep（v1.0.0，全文，含文档库版独有块）	§0 为什么需要 / §1 六层结构与单一来源（含 §1.1 L0.5）/ §2 分层判据 / §3 Lint 四件套 / §4 漂移 SOP / §5 自动化的边界 / §6 反例 / §7 自检 / §8 无效信息与高价值写法（含 §8.6 注入预算）/ §9 技能集体检 10 层 / §10 技能重组 / §11 归档镜像治理
references/01-过程与定稿分层.md	dsh-architecture-lifecycle（v1.0.0，全文）	§0 为什么需要 / §1 两个目录一个判据 / §2 命名约定 / §3 收敛五步 / §4 过时档案处理 / §5 定稿三道验收 / §6 目录 README / §7 与既有技能分工 / §8 自检 / §9 反例 / §10 判据速查
references/dsh-knowledge-upkeep/	原附属档	10-技能重组-千行技能拆分.md · split_skill.py

🔴 两个原名已退役（dsh-knowledge-upkeep / dsh-architecture-lifecycle）⇒ 别处见到按本技能对应档读。 ⚠️ 就绪提示：本技能可以用自己重组自己 —— §1 的技能重组四步 ＋ 各项验收，就是它自身这一形态的依据。