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`，包含：

```markdown
# 审稿报告 第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"