Mmcp.market

short-drama-novel-analyze skill

by zenstory-ai·zenstory-ai/drama-skills·2.3k stars·MIT

把长篇小说、连载网文或多集散稿拆成可追溯的原著分析:章节索引、改编价值快评、逐章功能提取、剧情单元与节奏聚合、人物与设定归并,最后给出改编价值判定与分集候选,交给 $short-drama-develop 立契约。用户说“导入这本小说”“拆这本书”“分析原著”“这本书能不能改短剧”“先看看值不值得拆”“把长篇拆成分集候选”,或直接给出小说文件路径时使用。只做只读的结构化分析,不写剧本、不建资产、不生成媒体,也不替创作者决定改编方案。

A100/100content scan

Is the short-drama-novel-analyze skill safe?

Clean: nothing in its files matched our rules. We read 9 files in the folder on 2026-09-28.

No findings.

Install the short-drama-novel-analyze skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.

git clone --depth 1 https://github.com/zenstory-ai/drama-skills.git /tmp/drama-skills
mkdir -p ~/.claude/skills
cp -r /tmp/drama-skills/skills/short-drama-novel-analyze ~/.claude/skills/short-drama-novel-analyze
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

长篇原著分析

把一部长材料变成能被引用、能被反驳、能被接着用的分析层。目标不是复述剧情,而是找出 每一段承担的戏剧功能,并说明它在竖屏短剧里值多少钱。

分析永远是候选。哪条线保留、哪些人合并、从哪里开篇,是创作者的决定,由 $short-drama-develop 立成改编契约。本技能不替它决定,也不批准自己的产物。

Quick Start

离线验证章节索引、采样和源文件变更检测:

python3 {技能目录}/scripts/selftest.py
python3 {技能目录}/scripts/novel_index.py index <原著.txt> --out <chapter-index.json>

开始前

本技能可独立安装和执行。先读取用户明确提供的原著与本任务直接输入;若当前目录是 short-drama 项目且项目工具可用,可以读取 status 并使用其发布生命周期,但缺少 core 或任何其他技能都不是分析工作的阻断条件。完整边界与规则见 阶段契约,无需读取其他技能的文件。

材料前提

只分析创作者合法持有、拥有使用权的作品。分析是只读的转化性工作:提取结构与功能, 不复制原文成段落,不把原句搬进下游产物。

通俗题材里的暴力、复仇、背叛、情爱张力与黑暗伦理是常规虚构叙事元素,照常做结构化提取。 个别片段无法处理时跳过该段并记录,不要因此中止整章或整本——中止会让后续所有阶段拿到 一份有洞却看不出洞在哪的分析。

先判断入口

没有字节就没有 span,没有 span 的分析无法被引用,也无法被反驳。

  1. 只有书名,没有原文:请创作者提供文件路径或粘贴正文。不要凭书名回忆情节——

输入/ 与输出目录 项目开发/source-analysis/work/;把原文字节复制到 输入/ 后记录 原始文件位置,再用本技能的 novelindex.py 建索引。若 $short-drama 可用,可选用它 初始化同样的目录和发布生命周期,但不得把 core 安装变成开始分析的前提。

  1. 有原文,未建项目:直接建立一个本技能自己的工作区,至少包含只读输入目录

不重跑已完成阶段。

  1. 有原文,项目已在:直接进入管道。
  2. 已有部分分析:读 项目开发/source-analysis/_progress.md 从断点续跑,

管道

输入/ 是不可变的创作者输入,本阶段只读它。全部产出落在 项目开发/source-analysis/。 独立工作区与完整项目使用同一套相对路径,因此后续安装 core 时无需迁移分析产物。

S0 章节索引

索引是唯一切片真源,由 章节索引脚本 建立。每个阶段各跑 一次正则,就会切出互相对不上的章节,第 47 章按一种边界分析、按另一种边界聚合, 而且没有人会发现。

python3 {技能目录}/scripts/novel_index.py index 输入/{原文文件} \
  --out 项目开发/source-analysis/_work/_index.next.json
python3 {技能目录}/scripts/novel_index.py verify \
  项目开发/source-analysis/_work/_index.next.json 输入/{原文文件}
# 项目工具可用时可选:
python3 {core 技能目录}/scripts/project_tool.py publish {项目根} \
  --owner short-drama-novel-analyze --artifact-id source-analysis:index \
  --output 项目开发/source-analysis/_index.json=项目开发/source-analysis/_work/_index.next.json \
  --input 输入/{原文文件}

脚本识别阿拉伯数字与中文数字章号(含 千 / 两,覆盖千章以上连载),只认一种编号单位 (章/回/节里出现最多的那个,其余记进 ignoredheadingunits),只把短的独立行当标题 (以章号开头的正文段落记进 longheadinglinesskipped),剔除开头的目录块, 按卷分段校验编号。它不做编辑判断**——哪章重要、 讲了什么,是后面阶段的事。

problems 非空就停下报告,不要带着错表进 S1。常见四种:章号跳号(缺章或抓错标题)、 同卷内重号、正文极少的章(多半抓到了目录残留或卷首页)、无法解析的章号。 另外确认三个计数:chapterunit 与 ignoredheadingunits——一本用 第N章 分章、 用 第N节 分小节的书应当看到 chapterunit: 章 且 节 被记入忽略计数,反过来说明分章单位 判断错了;longheadinglines_skipped 明显偏大时,多半是这本书的章节标题确实很长, 需要与创作者确认后手写边界。

原文本身没有章节标题时索引会返回空表,此时与创作者确认按什么切分,把边界写进 work/index.next.json,通过 verify 后再按上面的公开生命周期发布——手写的行也要带齐 sequence / linestart / lineend,verify 会逐行检查并报出缺字段的行。

改了原文必须重建索引,不能沿用旧 span。verify 核对编号、顺序与行号覆盖,所以插行删行会被报出来; 但同行数的原地改写不会——那一步靠改原文的人自己重建,套件不比对字节。

python3 {技能目录}/scripts/novel_index.py verify \
  项目开发/source-analysis/_index.json 输入/{原文文件}

S1 改编价值快评

回答这本书值不值得花全量拆解的成本。判据是全书的改编密度——screenready 单元占多少、 proseonly 占多少、制作负担压在哪几段——所以快评横跨整本书,用脚本抽样:

python3 {技能目录}/scripts/novel_index.py sample \
  项目开发/source-analysis/_index.json --count 12

抽样确定、可复现、首尾必取,跑第二次引用的是同一批章。按 改编价值快评 写 triage.md,覆盖六件事: 故事框架、三类判定比例、开篇替换点、制作负担量级、最大的三处改编风险、分集候选量级。 第一行写覆盖率(脚本返回的 coverage_ratio),所有结论限于抽样范围。

这里停靠问创作者:给出快评与全量拆解的预计耗时(按章数粗估),问是否继续。 创作者一开始就明确说「一次跑完」时仍写 triage.md,但不停下等待——它是 S5 要回填 对照的第一版假设。

停靠时把 progress.md 的状态写成 pausedafter_triage,断点写「下一步:S2 逐章提取」。

S1–S5 的 Agent 创作产物同样先写到 source-analysis/work/,完成本阶段机械检查后再发布到 上表中的正式路径。项目工具可用时用 projecttool.py publish 和稳定 artifact-id;独立运行时 原子替换正式文件。不要用半成品覆盖 index.json、progress.md、chapters/.md 或聚合产物。 work/ 是候选工作区,不是权威分析层,也不进入交付包。

并发子代理写 work/,主线程发布到正式路径。子代理只落 work/chapters/ch--extract.md,主线程跑完机械自检后再发布到 chapters/。 覆盖率闸门按正式路径 chapters/ 匹配文件名——发布之前跑,每一章都会进 unmatched_files,那不是缺陷,只是跑早了。

_progress.md 每个阶段都会重写,而发布要求一个路径只有一个 owner,所以它用一个固定 artifact-id:source-analysis:progress,owner 是 short-drama-novel-analyze, S0–S5 每次停靠都用同一个 id 重新发布。

S2 逐章功能提取

按 章节提取 处理每一章。能并发子代理就分批并发 (每批 5–8 章,等一批落盘再发下一批),不支持就串行——两条路径的写法要求和自检是同一份, 只是速度不同。

每章提取完落到 chapters/ch--extract.md, 是索引里的 sequence,不是原文章号 (多卷书的原文章号会重复,sequence 不会)。全部落盘后跑覆盖率:

python3 {技能目录}/scripts/novel_index.py coverage \
  项目开发/source-analysis/_index.json 项目开发/source-analysis/chapters

missing 非空就补跑缺的章;unmatchedfiles 非空说明有文件名写歪了——它既不算覆盖, 也不会被当成缺章,必须改名而不是重跑。不要在覆盖率不足时进入 S3**——聚合会照样产出 一份读起来完整的结果,而缺掉的章不会在任何地方留下痕迹。

单章连续失败两次就标记跳过,写进 _progress.md 的失败记录,并在后续每一份聚合产物里 注明该章缺失。失败可以接受,失败被藏起来不行。

S3 剧情单元与节奏

从逐章提取聚合,不回头重读原文——原文已经在 S2 被读过一次,再读一次只会得到第二份互相 矛盾的事实。按 聚合与实体 先识别故事框架 (框架决定按什么切单元),再产出:

跨章伏笔与兑现,以及按观众收益排名的爽点表。

  • story-units.md:把情节点归成有始有终的单元,每个单元记录进入状态、冲突、代价与出去状态;
  • rhythm-and-emotion.md:关键信息如何逐章推进、情绪触动点的铺垫→释放→余波、

聚合完成后跑同一文件里的三条阈值自检(归属置信、覆盖率、重叠率)与散落情节兜底。 阈值不是评分,是边界模糊的信号:重叠率过高说明两个单元其实是一个。

S4 人物与设定

按 聚合与实体 归并人物(跨章去重、别名归一、 分级),并从提及数据归纳世界规则、力量体系与势力。别名只有专名与有同指证据的绰号能合并, 描述性称谓与头衔永远不触发合并。

人物归并是候选,不是资产。 这里的人物条目带 unresolved 与来源引用, 交给 $short-drama-develop 定改编决定、$short-drama-write 写进剧本之后, 才由 $short-drama-assets 从已接受剧本建立真正的资产身份。绕过这条链直接建资产, 等于让原著的人物表冒充剧本的出现证据。

S5 改编价值与分集候选

这是本技能与通用拆书的分水岭。按 改编价值 产出:

(内心戏、叙述性诡计、长铺垫)在画面上无法兑现;制作负担落在哪里。

  • adaptation-value.md:哪些单元在竖屏短剧里能直接成立、哪些要换载体、哪些是纯文字快感

或字数平均切。每条带来源 span、承担的功能、承接的爽点以及未决项。

  • episode-candidates.jsonl:按爽点分布、局部戏剧结果与精确交接切出的候选集,不按章号

同时回填快评:S1 的哪几条判断被全量结果推翻了,写进 adaptation-value.md 的开头。 一个抽样结论被证伪,比它被悄悄忘掉有用得多——下一本书的快评会因此更准。

样例见 分集候选样例。

交接

More skills from zenstory-ai/drama-skills

  • Ashort-drama基于文件系统初始化和继续短剧或漫剧项目,提供 creator-first 五文档路由、本地 Dashboard、制作形态与 Look Development 决策。用户提出“创建/继续短剧项目”“看进度/下一步”“做 Look Development”“打开 dashboard/短剧创作台”“导出制作资料”,或任务跨多个创作阶段时使用;明确的写作、资产、提示词、分镜、剪辑或审查请求由对应子 skill 直接处理。
  • Ashort-drama-assets从短剧剧本拆出人物/造型、地点/视图、道具/状态和跨场连续性,写成创作者可读的视觉设定。用户说“拆角色/场景/道具”“做资产设定”“判断复用还是新变体”“更新造型/道具状态”,或拿现成剧本直接做视觉资产准备时使用;不写图片提示词,不生成媒体。
  • Ashort-drama-develop将中文小说、短剧或漫剧想法、梗概、改编材料、已有系列笔记或多集完整剧本发展成可追溯的改编方案、戏剧方向、创作简报、导演阐述、故事引擎与分集地图,并按题材与制作形态(画风)选择写法。用户提出“导入小说做短剧”“从多集整稿生成/补分集地图”“开发短剧/漫剧”“做故事设定/系列大纲/分集规划”“写导演阐述”“这个题材怎么写”“定画风/制作形态”“把这个点子变成短剧”或需要梳理人物冲突与集间交接时使用;已有单集剧本可直接进入写作、资产或审查流程,不强制补开发文件。
  • Ashort-drama-edit将已生成的短剧镜头剪成成片,记录入出点、镜序、声音、字幕与交付规格。用于套剪、加字幕、统一响度、调整节奏或导出精修素材;需要补素材或修改故事时转回对应创作阶段。
  • Ashort-drama-image-prompts为短剧人物、造型、地点、道具和状态编写或修改可直接复制的图片提示词 Markdown。用户提到角色设定图、三视图、参考图、场景板、道具图、风格帧、Look Development、状态变体或局部编辑提示词时使用;不生成图片,也不调用供应商。
  • Ashort-drama-knowhow维护者专用的短剧 know-how 学习、验证与生命周期治理。仅在维护者明确要求从其当前会话提供的授权只读文本源学习完整短剧项目链,并把私有观察逐步转成去标识、去复刻、经盲测与独立审查的公共 reference、rubric 或 synthetic fixture 候选时使用;不用于普通创作、公开运行时取数、媒体生成或粗略数据分析。
  • Ashort-drama-produce在创作者明确确认后,执行短剧项目的图片、视频、TTS/配音或时间线音乐生产任务,并把结果与精简运行记录落回项目。用户说“生成这张图/这段视频/这句配音/这段配乐”“开始跑图/跑视频/合成语音/生成音乐”“把已确认提示词送去生产”,或要求批量执行已确认媒体任务时使用;不负责创作提示词、镜头、台词、歌词或声音身份,也绝不把预览、继续、预算说明或既有接受状态当作本次付费生产确认。
  • Ashort-drama-review审查短剧项目中的原著分析、故事、剧本、视觉设定、图片提示词、分镜、冻结关键帧、视频提示词和已有媒体。用户提出“审稿/检查剧本”“检查资产或连续性”“检查图片/视频提示词”“检查原著分析”“审查模板感”“根据生产观察做项目校准”时使用;只写审查问题、结论和修订要求,不代替 owner 修改来源文件。
  • Ashort-drama-storyboard把中文短剧剧本和视觉设定写成有戏剧职责、连续性边界与冻结关键帧提示词的分镜 Markdown。用户提出“拆分镜/设计镜头/做镜头表”“场次视觉计划/调度故事板”“比较导演方案”“写首帧/关键帧提示词”或检查轴线、站位、视线、持物连续性时使用;不生成媒体。
  • Ashort-drama-video-prompts把短剧分镜和冻结关键帧写成可直接复制的视频提示词 Markdown,也可按用户要求写时间线配乐/主题曲意图。用户提到文生/图生视频动作、人物表演、运镜、口型、环境运动、镜头时长、起止状态、把分镜转成视频提示词或写配乐提示词时使用;不生成媒体、不创作歌词、不改分镜边界。
  • Ashort-drama-write编写或修订可拍摄的中文短剧、漫剧单集 Markdown 剧本,也负责保留作者原文地规范化现成剧本。用户提出“写/改一集短剧”“把大纲写成剧本”“优化场景/对白”“去模板感”“去 AI 味润色”“续写下一集”或提供剧本要求进入后续制作时使用;不负责资产、分镜、媒体提示词或终审。

All agent skills → · MCP servers