| name | self-contained-auditor-yashu |
| description | 评审一个技能是否「自包含」——即其知识、经验、规范是否全部内置在技能文件内（SKILL.md + references/），不依赖特定 AI 客户端专有的知识接口命令（如 read_me / modules: / show_widget / Visualizer）去外部拉取，也不硬编码某个 AI 软件的私有路径（如 .workbuddy）。同时检查工具依赖（node、浏览器、命令行）是否仅作为用户自备工具声明、未写死私有路径。当用户要求「评审这个技能是否自包含 / 独立」「检查技能知识是否内置」「审查技能的独立性 / 可移植性」「audit / review a skill for self-containment」时触发。产出评审报告：结论（自包含 / 不独立）+ 问题清单（文件:行号 + 引用的外部依赖 + 为何影响独立性）+ 整改建议。 |
自包含技能评审器
对一个指定技能做静态评审，判断它是否「自包含」：知识、经验、规范全部写死在技能自身文件里，不依赖宿主 AI 客户端的专有知识接口，也不写死某个 AI 软件的私有路径。本技能只读取目标技能的文件做分析，不实际运行目标技能。
何时使用
- 用户要求「评审这个技能是否自包含 / 独立」「检查技能知识是否内置」「审查技能独立性 / 可移植性」「audit / review a skill for self-containment」。
- 也可在交付或接收一个新技能前做自检。
评审的两个维度
- 知识自包含（核心）：规范、经验、领域知识是否全部在技能文件内（SKILL.md + references/）。若技能需要调用宿主专有命令去「拉取」规范 / 设计系统 / 知识，则知识未内置 → 不独立。
- 宿主绑定：是否硬编码了某个特定 AI 客户端专有的命令或私有路径（如
.workbuddy、其他软件的专属目录）。写死则技能无法在其他客户端使用 → 不独立（破坏可移植性）。
工具依赖不算不独立：Node.js、Python、浏览器、命令行工具等属于「用户自备工具」。要求仅在于：技能里应声明这些工具由用户提供，且不应硬编码某个软件的私有路径来指向它们。
工作流
-
定位技能目录。 用户会给出技能路径或技能名。定位其目录，确认存在 SKILL.md，以及可能存在的 references/、scripts/。
-
读取全部文件。 用 Read 工具读取：
SKILL.md（全文）references/ 下每个文件scripts/ 下每个文件（至少扫一遍，看是否引用宿主私有路径）
若文件很多，先读 SKILL.md，再按需读 references / scripts。
-
按评审清单逐项核对。 加载 references/checklist.md，逐项检查：
- 是否出现宿主专有「知识接口」命令（read_me、modules:、show_widget、Visualizer 等）且用于获取规范 / 知识。
- references / 是否存在且内容完整（而非占位或仅指向外部）。
- 是否写死某个 AI 软件的私有路径（
.workbuddy、其他软件目录）。
- 工具依赖是否声明为「用户自备」，未写死私有路径。
- 是否有「若 X 不可用则回退到 references」之类的措辞（说明首选外部、内置只是兜底）。
-
记录每条发现，含：文件路径、行号（尽量精确到行）、引用的原文片段、属于哪个维度、为何影响独立性、严重度（阻断 / 建议）。
-
给出结论与整改建议，按 references/report-template.md 的结构输出报告。结论为「自包含」或「不独立（N 处问题）」。每条问题给出具体改法（例如：把被 read_me 拉取的设计系统复制进 references/design-system.md，第 1 步改为读该文件）。
判定原则
- 仅当两个维度都通过才判「自包含」。
- 知识靠外部命令拉取 = 阻断级不独立。
- 写死宿主私有路径 = 阻断级不独立（除非该路径是「用户需自行替换的占位」并在文中明确说明）。
- 工具依赖但声明清楚、无私有路径 = 通过。
自带资源
references/checklist.md——自包含评审清单（知识内置检查项、宿主绑定检查项、工具依赖豁免项）。references/report-template.md——评审报告模板。
