القائمة
从老旧黑盒代码反推「树形索引、逐层下钻」的知识库（业务逻辑/数据库/接口三层），给重构 AI 注入背景。承诺「边界内可审计覆盖 + 残余风险显式登记」，不承诺零遗漏。触发词：「老代码考古」「反推知识库」「重构前背景」「把老项目翻译成文档」「legacy 调查」。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
对抗评审 skill。主线程把待评审内容（设计文档 / 代码 / 任意方案）原样打成证据包，并行起 Claude(Opus) 子线程与 codex(GPT 5.5) 做两份独立评审，再由 Opus 裁判逐条裁决采纳/驳回，产出最终报告。Claude 轮用 Agent 工具，GPT 轮用 codex。触发词："克劳德评审"、"对抗评审"。
Use when the user wants to consult Claude for a second opinion, audit, or direct execution. 触发词："问一下克劳德"、"问一下claude"、"问一下sonnet"、"让克劳德去做"、"让claude直接XX"、"问一下opus"、"让opus去做"。This skill uses the Agent tool to spawn a Claude subagent from the main thread. All synthesis and decisions stay in the main thread.
让 Opus 子线程处理最复杂的分析和执行任务。触发词："问一下opus"、"让opus去做"。主线程（L1）制包，Opus（L3）深度推理。
让 Sonnet 子线程分析或执行任务。触发词："问一下sonnet"、"问一下claude"、"让sonnet去做"、"让claude去做"。主线程（L1）制包，Sonnet（L2）深度推理。
从现有代码冷启动、生成七层文档反推总控文档的 skill（用户级通用）。本 skill 的交付物是「扫描摘要 + 任务总控编排文档」，不包含具体层的文档撰写（Phase 3 由 /control 驱动，单独消耗会话预算）。适用场景：项目无文档或文档严重过时、需要系统性规划七层文档补写任务。触发词：「冷启动建文档骨架」「反推文档体系总控」「从代码反推文档」「代码到七层」「反推文档体系」。
读陌生项目代码，自动组建 agent team，产出 AI 友好的项目导览文档（AI-friendly project guide）。 触发词：理解陌生项目、生成项目导览文档、代码到说明书、AI 友好项目文档、摸清一个代码库、 分析这个项目、给这个项目做文档、项目说明书、项目调研文档。 定位：只读调研 + 一次性产出，轻量级。 不是七层文档体系（code-to-7layer / doc-layer-system），不改代码，不需要人工逐步指导。
| name | legacy-archaeology |
| description | 从老旧黑盒代码反推「树形索引、逐层下钻」的知识库（业务逻辑/数据库/接口三层），给重构 AI 注入背景。承诺「边界内可审计覆盖 + 残余风险显式登记」，不承诺零遗漏。触发词：「老代码考古」「反推知识库」「重构前背景」「把老项目翻译成文档」「legacy 调查」。 |
把一个黑盒老项目反推成「树形下钻、业务/库/接口讲清」的知识库，给后续重构的 AI 做背景注入。 承诺只到「边界内可审计覆盖 + 残余风险显式登记」——不吹「我没漏」，只保证「我已识别的盲区、未证实项、未获取的真值源都显式登记了」。
这个 skill 是一个编排器，不是文档生成器。它指挥主 agent 粗扫、切块、派出 agent team 逐模块调查，把结果汇聚成一棵 README 层层索引的知识库树。一个项目一棵树，多个项目共享一个 平台层调用图。重构 AI 平时只读 L1，要哪块钉哪块往下读：省上下文，又能审计到每一处盲区。
本 skill 不承诺「业务逻辑零遗漏」。 白盒静态扫描无法证明「我枚举出来的 = 系统里全部」， 把无法证明的东西写成承诺就是自欺。
本 skill 承诺的是：① 边界内可审计覆盖（写下来的每条都有源码锚点、可回查）； ② 残余风险显式登记（没覆盖到的、没证实的、失传的，全部明确列出来，不藏）。
任何产物、任何对账，禁止出现「已查全 / 零遗漏 / 完整」字样。只能说「在已知枚举边界内已覆盖， 未覆盖部分见残余风险清单」。
本 skill 与 code-to-guide、code-to-7layer 机制有重叠，但定位不同。逐机制区别见
references/与现有skill边界对照.md。一句话：本 skill 只产「重构背景知识索引」，不产需求结论、
不产七层正式真值；能复用的已验证机制（fan-out、证据分级、硬暂停）尽量复用，不另造轮子。
这个 skill 的路径就是索引本身。 重构 AI「读 L1 → 钉下去」靠的全是各层 README 里的下钻链接， 链接就是相对路径。命名不钉死 → 增量建库（一次一个项目、跨多次运行）时结构漂移、导航断链。 所以路径规范是硬约束，不是建议。
<知识库根>/
README.md ← 平台总览（导航总入口）
_platform/ ← 下划线前缀，永远排最前、区别于业务项目
service-registry.md ← 稳定服务标识注册表（防重名 / 防仓名漂移）
call-graph.md ← 服务调用图（稳定标识做主键 + 悬空边 + 待接通清单）
platform-coverage.md ← 覆盖率总台账（各项目进度 + 残余风险汇总）
<服务标识>/ ← 一个项目一棵树
README.md ← L1：概况 + 模块清单 + 可选流程/场景索引 + 台账链接
discovery-ledger.md ← 发现来源台账（枚举策略 / 命中范围 / 未识别入口）
coverage-ledger.md ← 对象覆盖台账（逐对象认领状态）
<模块名>/ ← 裸名，无前缀
README.md ← L2：模块概览 + 下钻链接
business-logic.md ← L3 叶子（固定 ASCII 文件名）
database.md ← L3 叶子
api.md ← L3 叶子
README.md 作导航节点：列出本层子项 + 逐个下钻相对链接。缺一个就断链。business-logic.md / database.md / api.md。AI 不用猜去哪读。
core.quotepath / URL 编码锚点 /
grep 脚本上行为不一致（会被转义成乱码）。文件名/目录骨架用 ASCII，正文内容全中文。business-logic.md 写长了 → 升级成 business-logic/ 子目录（内含 README.md 索引 +
若干 business-logic-<子主题>.md）。升级方式固定，不让 AI 自由发挥。business-logic.md#锚点 的引用
（复用 long-doc-governance 的引用修复步骤）。漏修 = 断链。<服务标识> 是节点的唯一身份，登记在 _platform/service-registry.md。主 agent 全权调度，但不是无限自由——必须有预算、有终止、状态不放在记忆里。
子 agent 一旦派出，跑完才返回，无法中途停下来问用户。
所以一切「问用户 / 拿数据库 / 确认业务背景」的交互，只能发生在主 agent 层、在某一轮 fan-out 结束之后。 整个流程因此是回合制：派一轮 → 收齐回报 → 主 agent 消化（必要时问用户）→ 决定是否再派。
子 agent 在指令里被要求区分两类不确定：
宁可交一篇带明显空洞的半成品，也不要交一篇「自洽的错」。错的前提会污染整篇，对账还会显示「已认领」。
主 agent 收到「未决-阻塞」后，问完用户再补派一轮专门收口那个模块。这个阻塞收口轮也计入该模块的 N 轮预算（见 §3.3）；N 轮耗尽仍有阻塞点，一律降级为「待人工」封板，不无限收口。
扫构建文件（pom.xml / build.gradle）、依赖、注解，判定技术栈，推导本项目的枚举套路。
不预设栈——常见组合（Spring MVC/Boot、MyBatis、Feign/Dubbo、RocketMQ/Kafka、@Scheduled/Quartz）
的枚举锚点见 references/认栈枚举手册.md；认不出的栈走该手册的通用兜底法。
因为子 agent 中途停不下来（§3.1），凡是「需要用户给、需要外部系统拿」的东西，必须在派 team 之前 一次性问全，否则子 agent 只能干等或瞎猜。开工就向用户索要：
information_schema 表清单、crontab / 调度平台导出。
能拿几样拿几样；拿不到的，在台账里登记「该真值源缺失」。把「拿不到也得继续」设计进去：外部输入是增强不是前置阻塞。缺了就标低置信 + 登记盲区，不卡死。
覆盖率不能用一本账自证自己（台账由枚举生成，又拿台账给枚举对账 = 循环论证：枚举漏的项，台账里根本 没那一行，对账永远绿灯）。所以拆两本台账，再叠一层外部真值源差集。
discovery-ledger.md）记录**「我是怎么找的、找的边界在哪」**，而不是「找到了什么」。头部固定声明：
枚举来源：注解扫描 + MyBatis XML + Feign 接口 ← 用了哪些白盒手段
已知未覆盖：反射 RPC / 运行时动态拼接 SQL / 字符串拼 topic ← 白盒手段照不到的盲区，主动列出
外部真值源：网关路由表[已比对] / information_schema[未获取→DB 层标低置信] ← 每个真值源的获取与比对状态
「已知未覆盖」这一栏是诚实的核心——把白盒扫描照不到的地方主动列出来，而不是假装不存在。
coverage-ledger.md）机械枚举出的每个对象一行，认领状态收敛（见 §8）。列：类型 / 标识 / 源码锚点 / 认领文档 / 状态。
枚举类型：表、HTTP 接口、RPC、MQ 收发、定时任务、外部调用。模板见 assets/对象覆盖台账模板.md。
第一步·按服务边界裁剪真值源（关键，否则单项目视角会误报海量盲区）。 网关路由表 / 注册中心 /
broker topic / information_schema 通常是整个平台共享的，里面绝大多数路由 / topic / 库表属于
别的服务。一次只查一个项目，直接拿全平台真值源做差集，差出的「盲区」绝大部分是别家服务的噪声，
真盲区被淹没。所以先按服务边界过滤：
information_schema → 按本服务独占的库 / schema 名过滤第二步·裁剪后再做差集：
本服务的 information_schema 表 − 台账已枚举的表 = 白盒漏掉的表（盲区！）
本服务的网关路由 − 台账已枚举的接口 = 白盒漏掉的接口（盲区！）
本服务的 broker topic − 台账已枚举的 MQ = 白盒漏掉的 topic（盲区！）
第三步·逐项闭环，不许写一句汇总。 每个差出来的盲区登进发现来源台账的「外部差集盲区清单」 （逐项：对象类型 / 外部标识 / 真值源 / 白盒缺失原因 / 处置状态 / 认领文档 / 剩余风险）， 并且每一项要么补查后补进对象覆盖台账、要么明列入残余风险——禁止只留一句「发现 N 个漏掉的接口」。
拿不到外部真值源时，该类对象在对象覆盖台账的「分类置信度声明」里标 「仅白盒、未经运行时校验、可能漏列」——绝不给绿灯。
业务逻辑写到什么粒度，决定这个 skill 是「废话」「抄代码」还是「真有用」。
「新系统违反了就是 bug」→ 记录；「只是旧代码碰巧这么写」→ 丢弃。 即把「行为等价」翻译成动作：重写后必须保留才一致的，记；纯实现碰巧的，扔。
判断一条逻辑「是有意的业务规则」还是「碰巧的实现」，需要业务意图，而这恰是黑盒老代码最缺、 无业务背景的子 agent 最判不准的。所以：
正面 · 按业务决策类型分类（一条不漏）：
负面 · 条件保留（不再「必丢」）：
| 粒度 | 写法 | 判定 |
|---|---|---|
| 太粗 | 「系统会自动关闭超时订单。」 | ❌ 废话，重构 AI 学不到东西 |
| 刚好 | 触发:每 5 分钟扫【事实｜OrderJob:30】· 条件:待支付且超 30 分钟【事实｜OrderService:88】· 动作:置已关闭+回滚库存 · ⚠ 30 分钟是否可配【推测】 | ✅ 阈值/条件/副作用/不确定项齐全、挂锚点 |
| 太细 | 「OrderJob 用 @Scheduled 注入 OrderService，for 循环调 selectExpired()，执行 Mapper 88 行 SQL…」 | ❌ 在描述代码 |
绝不把「调用方:A、B」写成完整列表——跨服务的 C、D 可能在别的服务里，漏写会让重构 AI 误判「可以放心改签名」。
先读项目结构（包结构、模块划分、构建子模块），把项目切成若干内聚业务块。切块要点：
派出的每个子 agent 收到这样一份指令（照 task-control-doc §7.5 的「只读本职、做完即停」笔法）：
你负责调查【模块 X】，只产出三层：业务逻辑 / 数据库 / 接口。硬约束：
1. 不描述代码实现（不写类怎么继承、方法怎么调），只写「系统做什么决策、存什么数据、暴露什么契约」。
2. 每条业务规则必须挂源码锚点（文件:行 或 表.字段）。挂不上锚点的，不许写成事实。
3. 证据分级：代码能证=【事实｜锚点】；行为推断=【推测】；查到痕迹但细节已不可考=【待人工｜疑似失传】
（你无权直接标「失传」，那是主 agent 走完三件套+人工背书才能定的终态）；是不是业务规则拿不准=进「候选区」。
4. 不做「业务 vs 碰巧」的丢弃——只负责发现、保全候选、标证据强度（见粒度标尺 §5b.2）。
5. 区分两类不确定：
- 非阻塞 → 标【推测】或进候选区，继续写完。
- 阻塞型（不查清整篇就建立在错误前提上）→ 立即停笔、缩小该分支产出、
标「未决-阻塞」高优先级返回，其余非阻塞分支继续跑完。禁止瞎猜补全。
6. 产出落盘到指定文件，回填对象覆盖台账的认领状态。
7. 只做本模块，做完即停，把「待确认清单」（需用户补的业务背景 / DB 信息）随产出一并返回。
所有子 agent 回报落盘成结构化文件，主 agent 只读摘要（§3.3）。回报含：草稿、待确认清单、
「未决-阻塞」高优项、台账认领回填。回报落盘格式见 assets/子agent回报模板.md（本轮产出文件 /
台账变更 / 未决-阻塞清单 / 待确认清单 / 建议补派范围 / 轮次计数），主 agent 二轮补派据此稳定消费，
不靠从自然语言里捞。
从落盘的回报里读「待确认清单 + 未决-阻塞项」，决定：
持续到「无未决点」或触达单模块轮次上限（§3.3）。触上限则封板，剩余未决标「待人工」。
DB schema 在 §4.2 已尝试批量索要。若用户没给：
对象覆盖台账每一行的状态必须收敛到下列终态或显式中间态之一，无「待调查」残留：
| 状态 | 含义 | 进入门槛 |
|---|---|---|
| 已记录 | 有锚点、已写进某叶子文档 | 锚点齐 |
| 推测 | 行为推断、未被代码完全证实 | 标明推断依据 |
| 失传 | 已穷尽白盒 + 已问用户 + 用户确认不可考 | 三件套齐全 + 人工背书（缺一只能标「待人工」） |
| 待人工 | 还没问用户 / 超轮次封板 | —— |
| 未决-阻塞 | 子 agent 报的阻塞点，待主 agent 收口（仅过程态，对账前必须清空） | —— |
「失传」是终态，权力很大（标了就不再查、对账也收敛），所以门槛最硬：必须三件套齐全且有人工背书。 任何一件没做到，只能标「待人工」或「推测」，不许图省事洗成「失传」。子 agent 无权标「失传」 （它给不了人工背书），最多标「待人工｜疑似失传」；「失传」只能由主 agent 归并 + 人工背书后回填。
「未决-阻塞」是过程态、不是终态：最终对账前，所有未决-阻塞必须经补派收口转为「已记录/推测」， 或封板转「待人工」——诚实陈述里不出现未决-阻塞。
对账完成 ≠ 宣称查全。对账的产物是一句诚实陈述：
「在已知枚举边界内，N 个对象已记录 / M 个推测 / K 个失传 / J 个待人工（无未决-阻塞残留）； 外部真值源差集发现的盲区见发现来源台账的『已知未覆盖』与『外部差集盲区清单』。」
禁止输出「已查全 / 零遗漏 / 完整」。
收尾跑一道 adversarial-review，但职责是「残缺性审计」，不是「完整性保证」。
为什么改名：adversarial-review 拿文档评文档，能挑出「这条规则自相矛盾 / 这个分支讲不通」， 但它没有独立真值源去发现「代码里有而文档里没有」的未枚举入口——除非把整个老代码重扫一遍 （等于把考古重做）。所以它检不出「漏了什么」，只能检「写错了什么」。把它当完整性关卡是名实不符。
这一关卡让评审 agent 重点审：
产物是一份「残缺性审计意见」，补进残余风险清单。不宣称「审计通过 = 完整」。
每查完一个项目，往 _platform/ 增量补一笔，不要求一次建全。
service-registry.md 登记 / 查重（§2.4）。call-graph.md 的边用稳定服务标识做主键。被调方此刻可能还没建库 →
这条边是悬空边，显式标「被调方未建库」，并登进**「待接通清单」**。assets/：发现来源台账、对象覆盖台账、叶子文档（业务逻辑/数据库/接口三合一，含 L2 模块
README 迷你骨架）、项目主 README、平台调用图、子 agent 回报。项目特定值不硬编码进引擎，运行时由用户提供 / 项目补丁声明：
| 挂载项 | 取值方式 |
|---|---|
| 输出根目录 | 运行时问用户 |
| 快照批次号 | 运行时问用户（默认当天日期） |
| 公司特有技术栈的枚举锚点 | 项目补丁补进 references/认栈枚举手册.md 的扩展区 |
| 服务标识映射规则 | 项目补丁声明（如何从仓名/制品名映射到稳定标识） |
| 外部真值源获取方式 | 运行时问用户（网关/注册中心/DB 在哪） |