Novel review
长篇小说写作与审稿 Claude Code plugin。题材中性 — 校园青春、悬疑、武侠、科幻、历史、都市等长篇均可。包含 5 个 skill + 12 个 agent + 8 篇通用写作技法 reference。
npx -y skills add chaserr/novel-craft --skill novel-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
长篇小说审稿调度器。根据用户的审查诉求决定召唤哪些 novel-* agent(架构 / 逻辑 / 节奏 / 伏笔 / 文笔 / 对话 / 场景 / 读者 / 资料),聚合各角色报告并归档到审稿报告目录。触发词:审稿、审一下、找问题、稿件诊断、novel-review。
SKILL.md
5.0 KB, as published. Nobody here has run it
novel-review
用途:长篇小说审稿的总调度器。把"审稿"这件事拆给合适的 novel-* agent 去做,最后汇总并归档。
输入要求
- 审查范围(必须):单章 / 章节区间 / 全书摘要
- 审查类型(可推断 / 可显式指定):
- 全维度(默认):所有相关 agent 走一遍
- 结构向:novel-architect + novel-pacer + novel-plotter
- 文字向:novel-polisher + novel-dialogist + novel-scene-refiner
- 逻辑向:novel-auditor + novel-plotter + novel-researcher
- 读者向:novel-reader
- 元层:novel-curator(≥3 章已审后才有意义)
执行流程
第 1 步:上下文加载
读取:
RTK.md(题材气质 + 文风底线 + 红线)- 用户指定范围的章节正文
小说大纲.md/章节大纲.md(结构参考)前情梳理.md/伏笔清单.md(线索参考)人物档案/*.md(一致性核查参考)审稿报告/审稿进度与问题台账.md(如存在,了解历史问题,避免重复指出)
如缺 RTK.md,拒绝执行并提示先 novel-init。
第 2 步:确认审查计划
向用户输出:
【审稿计划】
范围:第X章 - 第Y章(约 N 万字)
类型:全维度审查
将召唤以下角色(并行):
- novel-architect → 结构/大纲层面问题
- novel-auditor → 逻辑/设定/时间线
- novel-pacer → 节奏曲线、爽点密度
- novel-plotter → 伏笔、支线、情感账单
- novel-polisher → 风格、文笔、陈词滥调
- novel-dialogist → 对话辨识度(仅当对话密度 >30% 时)
- novel-scene-refiner→ 场景描写(仅当章节有大段场景)
- novel-reader → 目标读者主观反馈
- novel-researcher → 背景真实性(仅当涉及真实学校/年代/地域/专业领域)
预计:每角色独立报告 + 一份汇总。
是否开始?(可调整角色清单)
用户确认或调整后进入下一步。
第 3 步:并行调度 agent
并行调用所选 agent,每个 agent 拿到的输入:
- 章节范围与正文
RTK.md(题材气质)前情梳理.md/伏笔清单.md(如该 agent 需要)人物档案/*.md(如该 agent 需要)- 用户的特殊审查诉求(如有)
- 历轮审稿沉淀(避免重复指出已知问题)
每个 agent 按其自身规定的输出格式独立产出报告。
第 4 步:汇总到《本批审稿报告》
收齐所有 agent 报告后,生成一份汇总报告 审稿报告/审稿-第NN批-第X-Y章.md,包含:
# 审稿报告 第NN批|第X章 - 第Y章
## 一、总体判断
[3-5 句话:完成度 / 优势 / 最大风险]
## 二、各角色发现汇总
### 结构层(novel-architect)
[关键发现 + 严重级]
### 逻辑层(novel-auditor)
[关键发现]
### 节奏层(novel-pacer)
[关键发现]
### 多线/伏笔(novel-plotter)
[关键发现]
### 文字层(novel-polisher / dialogist / scene-refiner)
[关键发现]
### 读者反馈(novel-reader)
[评分 + 关键反应]
### 背景核查(novel-researcher,如有)
[关键发现]
## 三、问题严重度矩阵
| 编号 | 类型 | 严重级 | 来源角色 | 建议处理角色 |
|------|------|--------|---------|-------------|
| ... | ... | 致命/重大/一般 | ... | ... |
## 四、优先修改清单(按重要度排序,前 5 项)
1. ...
2. ...
## 五、值得肯定的部分
[正向反馈,避免只输出问题]
## 六、需用户裁决的争议建议
[不同 agent 给出冲突建议时的并列呈现]
## 七、跨章 / 全书级线索(仅做提示,不在本批解决)
- ...
第 5 步:更新审稿台账
把本批审稿的"未解决问题"追加到 审稿报告/审稿进度与问题台账.md,方便后续批次累计追踪。
第 6 步:如果累计已审 ≥3 章,建议 curator
每完成 3 批以上审稿后,主动建议用户:
已累计 N 批审稿,建议召唤 novel-curator 做一次知识提炼,归纳作者反复出现的问题模式,建立长期改进路线图。
红线
- 绝不让单个 agent 越界做不属于它的工作(例如让 polisher 改情节)
- 绝不在汇总时偷换角色的原始判断;冲突建议必须并列呈现
- 绝不在没有
RTK.md的项目里跑审稿 - 单批次审稿最多 5-6 章,避免上下文超载;范围太大时主动拆批
触发示例
- "审一下第 10-15 章"
- "找一下第 23 章的问题"
- "节奏诊断第 20-30 章"
- "请 reader 角色试读一下前 3 章"
- "/novel-review 10-15"