最值得处理的是下面这些

最值得处理的是下面这些：

严重：references 里塞进了很多“完整旧 Skill”，而不是纯知识参考。
比如 shanyin-screenwriting.md 自己写着“全局最高优先级”“严格按步骤顺序执行”“每一步完成后暂停等待用户通过”；而总控 SKILL.md 明明规定“信息足够时直接执行”。这两个逻辑会正面打架。导演参考里还有“激活后直接以王家卫/胡金铨/宫崎骏身份回应”之类指令。结果就是硬核导演加载参考后，有概率突然从总导演变成某个子 Skill 的人格和工作流。
最小修法不是删除这些知识，而是把 reference 全部“去 Skill 化”：删掉触发词、身份、激活规则、最高优先级、等待确认、独立工作流，只留下真正的方法论和知识。
严重：存在明确的“宣称有功能，但文件根本没打进去”。
例如 video-reverse-engineer.md 明确让系统运行 analyze.py，甚至写了文件结构包含 analyze.py + requirements.txt，但包里两个都没有。style-fusion.md 宣称有 fusion.py + style-database.json，也没有。story-master.md 描述 pipeline.py / ai_reviewer.py / episode_generator.py / graph_manager.py / data/pipeline_state.json，全部不存在。video-analysis.md 还描述了 case-library/index.json，同样没有。
这个问题比文档写得不好严重，因为它会让 Agent 以为自己拥有实际上不存在的工具链。要么把实现真正打进去，要么明确改成“方法论参考/伪代码，不提供执行脚本”。
严重：存在至少 11 个明确指向不存在文件的内部引用。
screenwriter.md 缺：examples.md、camera.md、composition.md、lighting.md、style.md、audio.md。
shanyin-screenwriting.md 缺：core-methodology.md、format-ultrashort.md、format-short.md、format-feature.md、format-series.md。
所以有些路径刚好走到那里，就会出现“要求先读取某文件 → 文件不存在”的死路。这是必须修的。
如果这是准备外发的版本，现在完全不干净。
我实际扫到大量明显来源痕迹：白梦客 出现约 63 次，还有女娲、山音、少年阿宾、CellCog、BytesAgain、mebusw，以及 GitHub 仓库地址、作者字段、源码出处、本地知识库路径。甚至 _meta.json 还保留了 ownerId: 443273。
另外还有诸如 ~/Documents/白梦客知识库/... 这种原始机器/知识库结构信息。
如果只是你自己本地用，这一点不影响运行；如果外发，这一项直接不通过。
但是不能简单“一键删除所有作者和来源”。
这里有些文件明确写了 MIT，有的写 CC0，也有外部项目来源。如果确实基于第三方代码/文本，外发时应该把运行态 references 清干净，同时单独保留一个合法的 THIRD_PARTY_NOTICES / LICENSES 文件处理需要保留的版权声明。
否则为了“看不出来源”把法律上要求保留的 notice 也抹掉，反而给自己埋雷。
路由有重叠，容易选错模块。
例如 video-analysis 和 video-reverse-engineer 都能被“拉片 / 视频分析 / 拆解视频”触发；几个短剧 Skill 也高度重合；screenwriter、shanyin-screenwriting、story-master 的边界还有交叉。
现在主要靠主 SKILL.md 勉强压住，但 reference 自己也带 trigger/工作流，所以加载后又会二次争权。最好明确成“总控唯一负责路由，reference 永远没有触发权”。
外部 Skill 依赖没有形成正式依赖合同。
主 Skill 里面直接引用 $scene-camera-reprojection 和 $hc-sd2-5-prompt-writer，但是它们不在当前包里。你虽然写了 fallback，但 scene-camera-reprojection 那一条甚至没有像 2.5 Writer 那样明确检查安装状态。
正确做法应该是统一做一个 Optional Dependencies 机制：存在就调用，不存在就自动降级，绝不能让任务中途卡死。
ai-scene-design.md 太大。
单文件 3919 行、约 17.5 万字符。虽然总控已经写了“先搜索对应标题再读”，思路是对的，但某些 Skill 环境读取 reference 并不一定足够聪明，可能整份吞进去。这样会白白浪费大量上下文。
我建议拆成空间拓扑、建筑与材质、灯光、视觉叙事、资产板、Prompt 编译等 5～8 个小模块，路由反而更稳。
旧版追溯文件 legacy-filmmaking-v1.md 不应该留在运行包里。
总控甚至主动告诉 Agent：“本目录保存了整合前的完整来源，便于追溯。”这恰恰等于主动给运行模型留了一条“回旧系统”的路。
如果需要追溯，应该放开发归档包，不应该进入正式 runtime Skill。正式包最好只有当前真源。
有一些内容质量也已经过时或过度绝对化。
例如部分旧 Prompt 模块大量使用“必须确认三个参数以后才能继续”“角色物理特征必须 8–15 个”“AI 不理解因果逻辑”这类很旧、很硬的经验规则。它们不是完全错，但放在 2026 年的总导演系统里当硬规则，会限制新模型。应该从“铁律”降级成经验策略，由当前平台和任务决定是否采用。