novel-review

name	novel-review
description	长篇小说审稿调度器。根据用户的审查诉求决定召唤哪些 novel-* agent（架构 / 逻辑 / 节奏 / 伏笔 / 文笔 / 对话 / 场景 / 读者 / 资料），聚合各角色报告并归档到审稿报告目录。触发词：审稿、审一下、找问题、稿件诊断、novel-review。
user-invocable	true
allowed-tools	Read, Write, Edit, Bash, Glob, Grep, Task, Agent, AskUserQuestion

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"