メニュー
适用于 drpy-node 新建 DS 源。用户提到“新建源”“写个 drpy 源”“分析这个站做 DS 源”“创建新规则”“从零开始做源”时使用。专注于站点分析、模板判断、规则生成与初步验证，优先走模板继承与最小覆盖路线，避免一开始就把修复、仓库上传等杂事混在一起。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
适用于 drpy-node 源的播放链路排查与 lazy 修复。用户提到“播放不通”“lazy 不对”“是不是直链”“play.html 被当直链”“iframe 提取”“m3u8 提取”“parse:0/1 判断”“假播放”“站外解析”时使用。专注于判断播放结果是否真实可播，并优先修复 lazy 逻辑。
适用于 drpy-node 源的仓库上传、替换、标签修正与上传前校验。用户提到“上传仓库”“替换上传”“改标签”“公开/私密”“仓库里的文件信息”“上传前检查”时使用。专注于确保上传动作规范、标签正确、结果可追踪。
适用于 drpy-node 新建 DS 源。用户提到“新建源”“写个 drpy 源”“分析这个站做 DS 源”“创建新规则”“从零开始做源”时使用。专注于站点分析、模板判断、规则生成与初步验证，优先走模板继承与最小覆盖路线，避免一开始就把修复、仓库上传等杂事混在一起。
适用于 drpy-node 源开发、修复、调试、测试与仓库上传的总控工作流 Skill。用户提到“修源”“调试 drpy 源”“测试某个源”“详情为空”“播放不通”“搜索异常”“上传到仓库”“修复 P0 源”“评估源可用性”“DS源开发”“lazy 解析”“上传 ds 源”时使用。优先用于 drpy-node 项目中的 DS 源，负责先评估、再分流到对应子 skill（播放调试/仓库上传/新建源），最后做结果汇总与上传决策。
适用于 drpy-node 源的播放链路排查与 lazy 修复。用户提到“播放不通”“lazy 不对”“是不是直链”“play.html 被当直链”“iframe 提取”“m3u8 提取”“parse:0/1 判断”“假播放”“站外解析”时使用。专注于判断播放结果是否真实可播，并优先修复 lazy 逻辑。
适用于 drpy-node 源的仓库上传、替换、标签修正与上传前校验。用户提到“上传仓库”“替换上传”“改标签”“公开/私密”“仓库里的文件信息”“上传前检查”时使用。专注于确保上传动作规范、标签正确、结果可追踪。
| name | drpy-node-source-create |
| description | 适用于 drpy-node 新建 DS 源。用户提到“新建源”“写个 drpy 源”“分析这个站做 DS 源”“创建新规则”“从零开始做源”时使用。专注于站点分析、模板判断、规则生成与初步验证，优先走模板继承与最小覆盖路线，避免一开始就把修复、仓库上传等杂事混在一起。 |
当本地环境已安装本 Skill 时：
如果已经命中本 Skill 的使用场景，不要退回到通用 MCP 基础流程充当主流程。
ruledrpy-node-source-workflow如果任务已经从“新建源”转变成以下任一情况，应交给总控 workflow：
drpy-node-play-debug如果主要问题已经明显收缩到播放链路，例如：
则应切换给 drpy-node-play-debug，不要在 create skill 里继续扩写播放排障。
出现以下任一情况时，必须停止继续在 create skill 内扩写，并明确切换到其他 skill：
drpy-node-source-workflowdrpy-node-play-debug禁止在这些前提已出现时，继续把 create skill 当成总控或播放专项 skill 使用。
当用户说“新建源 / 写个 drpy 源 / 分析这个站做 DS 源”时，优先按下面顺序起手：
不要一上来就大面积手写 一级/搜索/二级。
先分站型、先判断模板/签名接口、先保住最小可用，再决定是否需要最小覆盖。
当站点不是内置模板，且分类页列表明显由前端 JS 异步渲染时，必须优先参考：
references/references-non-template-signed-api-site.md不要看到页面上有 data-api 就直接假设这是可裸 GET 的 JSON 接口。
必须先确认：
time/key/token 等签名参数本类站点可能出现：
double当站点已命中内置模板，且通过模板继承生成最终 rule，但首页推荐节点已确认存在而 home.list 仍为空时，必须优先参考：
references/references-inherited-template-minimal-override-site.md如果手写 推荐 已经直接落到最终卡片层，例如：
.cbox_list&&ul&&li
而首页仍为空，不要立刻怀疑字段槽位全部错误，优先检查：
double: true
对于单层推荐结构，应优先尝试：
double: false
在处理搜索前，必须先阅读：
references/references-search-strategies.mdreferences/references-old-encoding-search-site.md尤其要先判断当前站点属于：
不要在没有完成这一步判断前，就直接拍脑袋写 searchUrl，也不要随手决定使用 suggest / RSS。
在新建源或初步验证阶段，如果 evaluate_spider_source 仅搜索失败，而首页 / 一级 / 二级 / 播放已正常，不要立刻回头重写搜索规则。
应优先判断是不是评估词不适配当前站点。evaluate_spider_source 的搜索词由 keyword 参数决定；若不传，默认词常为 斗罗大陆，这并不适用于所有垂类站。
优先主动传入更高频、更宽匹配、且更贴合站型的词进行验证，例如：
我的异世界、转生vod_name 的稳定片段如果换词后搜索恢复正常，应优先判定为评估参数问题，而不是直接把责任归到 searchUrl / 搜索 规则上。
* 先按“对齐一级”理解，再决定要不要覆盖当模板字段中出现：
搜索: '*'推荐: '*'推荐: '.xxx;*;*;*;*;*'* 的模板摘要写法必须先阅读：
references/references-template-summary.md不要在没有理解 * 的源码级行为前，就把它机械改写成完整手写规则。
*：整体继承一级*：按分号位置逐位继承一级对应槽位当站点明显命中模板时，不要一上来就手写 一级/搜索/推荐/二级。必须先完成这份核查清单。
class_parse 是否残留并覆盖 class_name/class_urldouble 是否导致首页推荐为空url 是否是真实分类模板，而不是首页导航表层链接searchUrl 是否是真实搜索模板fyclass/fypage一级/搜索，优先验证模板内置规则当模板站未完成模板继承核查前，禁止一上来就大面积手写：
推荐一级搜索二级优先顺序应为：
url/searchUrl|| 的推荐用法|| 应优先用于同一 selector 下的属性 fallback，例如：
img&&data-original||src
a&&data-original||src
不要默认生成这种“完整双规则 fallback”：
img&&data-original||img&&src
除非已经明确验证当前 parser / engine 显式支持。
这类写法看起来合理，但可能超出当前 htmlParser.js 的稳定支持边界，导致：
在生成字符串型规则时：
detailUrl如果继承模板站的二级字典看起来合理，但 detail 测试传纯数字 ID 时仍返回模板兜底值，应优先检查：
detailUrl
很多模板站 detail 真正失败的根因不是二级字典错误，而是引擎无法把纯数字 ID 映射成详情页 URL。
搜索结果为空时，要优先确认搜索页是否使用独立 DOM（如 .searchlist_item），不要默认 搜索: '*' 或一级列表结构可以直接复用。
当 一级: async function () {} 需要处理分类和页码时，优先直接使用：
this.MY_CATEthis.MY_PAGE不要先从 input 或 MY_URL 做正则拆参，除非引擎上下文确实未提供。
request/post 是全局函数，不在 this 上在 drpy async function 中：
request / post 应直接全局调用let { request } = thisvod_play_url 只吐出 1 集时，先检查 lists 容器层级不要看到详情页真实能抓到多个 <a>，就立刻否定二级字典方式或切到 async。应优先检查：
lists 是否落在了适合引擎逐项消费的容器层级#id 是否仅用于线路容器替换，而不是被误理解为控制单线路集数对于这类“一级异步接口 + 详情页直出资源列表”的动漫站，页面上：
.anthology-list-box:eq(0) .anthology-list-play 可抓到 1 个 ul.anthology-list-box:eq(0) .anthology-list-play a 可抓到 2 个 a.anthology-list-box:eq(0) .anthology-list-play li 可抓到 2 个 li但在 drpy 引擎的二级字典模式下，要稳定吐出多集，最终应优先尝试：
lists: '.anthology-list-box:eq(#id) .anthology-list-play li',
list_text: 'a&&Text',
list_url: 'a&&href'
#id 的主要作用是“线路容器替换定位”lists 落在 li 项层，而不是 ul 容器层lists 容器层级，再考虑放弃字典或切 async; 有固定槽位语义默认应按 drpy-node 引擎契约理解：
title: '片名;类型'img: '封面图规则'desc: '备注;年份;地区;演员;导演'content: '简介规则'tabs: '线路节点选择器'tab_text: '线路名提取规则'lists: '当前线路的选集列表选择器，支持 #id / #idv'list_text: '每一集标题提取规则'（默认 body&&Text）list_url: '每一集链接提取规则'（默认 a&&href）detail 时，必须使用一级真实返回的 vod_id禁止在 detail 测试时主观把 vod_id 简化成纯数字 id、短 id 或手工猜测的详情 id。
必须遵守：
categoryvod_idvod_id 去测 detail默认优先保证以下信息可用即可：
只有在用户明确要求，或先征询用户是否需要补全时，才继续完善：
如果 detail 还没有稳定产出：
vod_play_fromvod_play_url就不要急着把问题归因为 lazy / play 链路。应先回头检查：
tabs/lists/tab_text/list_text/list_url 是否匹配vod_id 是否来自一级真实返回class_parse 会压住 class_name/class_url如果继承模板后准备使用：
class_name: '电影&电视剧',
class_url: '1&2'
则必须检查模板是否自带 class_parse。
若模板残留的 class_parse 仍在生效，可能导致首页 class 为空，自动评估拿不到分类 ID。
优先显式补：
class_parse: ''
让 class_name/class_url 真正接管。
double如果首页真实存在推荐卡片节点，但 home.list 仍为空，要考虑模板默认推荐可能按双层定位处理。
对于实际是单层推荐结构的站点，应优先尝试：
double: false
double:falseurl 不能只看首页导航表面链接不要看到首页导航是 /list/1.html，就直接推断 url 模板是 /list/fyclass_fypage.html。
必须验证：
fyclass 与 fypage 的真实落位有些站首页导航是 /list/1.html，但真正可用的分类模板可能是：
/top/fyclass--------fypage---.html
另一些站则可能是：
/index.php/vod/type/id/fyclass/page/fypage.html
所以：
分类 url 必须通过真实网页和翻页结构验证，不可只靠表层导航推断。
如果 evaluate_spider_source 结果很差，不要立刻断言整份源不可用。
应优先用：
test_spider_interface(category)test_spider_interface(detail)test_spider_interface(play)分别验证单接口是否真实可用。
double、错误分类 URL）