@oh-story/dsh 0.1.10 → 0.1.12

package/lib/oh-story/skills/story-review/SKILL.md

@@ -6,7 +6,7 @@ metadata: {"openclaw":{"source":"https://github.com/zenstory-ai/oh-story-claudec
 ---
 # story-review：多视角对抗式审查
 
-> Spawn 版本提示（不阻断 spawn）：先读取项目根 `.story-deployed` 的 `agents_version`。与本版 `agents_version: 32` 不一致时（标记缺失、字段缺失/非整数、小于或大于 32）**照常按文件存在性检查并 spawn**，但只检查当前运行时的 canonical 目录；同时在「这次怎么审的」里用一句白话提示作者「审稿助手是旧版，运行 /story-setup 后新开会话」，`Notice: agents bundle 版本不匹配（项目 {N}，本版 32）` 原文写进技术备注行；大于 32 时额外提示先更新 oh-story-claudecode，不要用本地旧版 setup 降级覆盖。只有 agent 文件缺失、或运行时不暴露 custom agent 时才降级 solo/direct，报告 `Fallback: ... -> solo`。
+> Spawn 版本提示（不阻断 spawn）：先读取项目根 `.story-deployed` 的 `agents_version`。与本版 `agents_version: 34` 不一致时（标记缺失、字段缺失/非整数、小于或大于 34）**照常按文件存在性检查并 spawn**，但只检查当前运行时的 canonical 目录；同时在「这次怎么审的」里用一句白话提示作者「审稿助手是旧版，运行 /story-setup 后新开会话」，`Notice: agents bundle 版本不匹配（项目 {N}，本版 34）` 原文写进技术备注行；大于 34 时额外提示先更新 oh-story-claudecode，不要用本地旧版 setup 降级覆盖。只有 agent 文件缺失、或运行时不暴露 custom agent 时才降级 solo/direct，技术备注写 `Fallback: ... -> solo`。
 
 你是审查协调器。你的职责是找出小说文本中的结构、角色、文字、设定问题，并给出可执行修改建议。
 
@@ -16,7 +16,7 @@ metadata: {"openclaw":{"source":"https://github.com/zenstory-ai/oh-story-claudec
 
 ## 作者习惯边界
 
-若作者记忆 state 已存在，审查前用 `scripts/author_memory_commit.py query --kind delivery --kind interaction --kind prose_style --book-root {书目录}` 获取本次相关 active 条目（`--kind` 必传；不传 `--book-root` 就拿不到本书级偏好；总输出 ≤2KB）。它们只能帮助解释意图和组织报告，不能降低 rubric 严重度、把事实冲突判为无问题或跳过平台门禁；当前请求仍优先。完整规则见 [references/author-memory.md](references/author-memory.md)。
+若作者记忆 state 已存在，审查前用 `scripts/author_memory_commit.py query --workspace {工作区} --book-root {书目录} --kind delivery --kind interaction --kind prose_style [--genre {题材}] [--workflow 审稿]` 获取本次相关 active 条目（`--workspace`、`--kind` 必传；不传 `--book-root` 就拿不到本书级偏好；`--genre` 填本书题材类型；总输出 ≤2KB）。它们只能帮助解释意图和组织报告，不能降低 rubric 严重度、把事实冲突判为无问题或跳过平台门禁；当前请求仍优先。完整规则见 [references/author-memory.md](references/author-memory.md)。
 
 用户对报告格式或协作方式作出稳定声明时，在本轮审查完成后用 `record` 记录，并按 author-memory.md「回执怎么告诉作者」转告；只记作者明确说的，一次性要求不记录，不从反复修改推断。审查发现、工具告警和助手建议本身绝不自动学习。
 
@@ -35,7 +35,7 @@ metadata: {"openclaw":{"source":"https://github.com/zenstory-ai/oh-story-claudec
 
 1. **确定请求模式**：解析用户输入中的 `full`、`lean`、`solo`；未指定时目标模式为 `full`。
 2. **确认是否允许 spawn**：如果当前已经在子代理/Agent 内执行，不再递归 spawn，直接降级为 `solo`。
-3. **识别 ZCode 能力边界**：如果当前运行于 ZCode 且项目使用 `.zcode/`，ZCode 3.3.4 不执行项目/plugin custom agents；不要因为磁盘上存在其他端的 agent 文件就尝试同名 spawn，直接降级 `solo` 并报告 `Fallback: project custom agents unavailable -> solo`。
+3. **识别 ZCode 能力边界**：如果当前运行于 ZCode 且项目使用 `.zcode/`，ZCode 3.3.4 不执行项目/plugin custom agents；不要因为磁盘上存在其他端的 agent 文件就尝试同名 spawn，直接降级 `solo`，技术备注写 `Fallback: project custom agents unavailable -> solo`。
 4. **检查核心 Agent 部署状态**（只检查当前运行时的 canonical 目录，不因其他端文件存在而误判）：
    - Claude Code 检查 `.claude/agents/`，OpenCode 检查 `.opencode/agents/`，Codex 检查 `.codex/agents/`，Antigravity 检查 `.agents/agents/`
     - full 必需 agent：`story-architect`、`character-designer`、`narrative-writer`、`consistency-checker`
@@ -46,8 +46,8 @@ metadata: {"openclaw":{"source":"https://github.com/zenstory-ai/oh-story-claudec
       - **Codex agent（`.codex/agents/`）**：文件名为 `{agent}.toml`，TOML 必须可解析，且包含 `name`、`description`、`developer_instructions`；`name` 必须与目标 agent 完全一致。
       - **Antigravity agent（`.agents/agents/`）**：路径为 `.agents/agents/agent-name/agent.md`（`agent-name` 为目标 agent 名），frontmatter 必须可解析，且 `name` 与目标 agent 一致、`mainAgent: false`、`subagent: true`、`tools` 非空；缺失或不匹配视为 malformed。
    - 如果目标模式所需任一文件缺失或 malformed，**不要尝试 spawn 缺失/异常 Agent**；自动降级为 `solo`，报告开头用一句话告诉作者「审稿助手缺失或损坏，这次由我一个人审；运行 `/story-setup` 后可多视角审」，降级原因 `missing agents -> solo` / `malformed agents -> solo` 与问题文件写进技术备注行的 Fallback、Files 两栏。
-5. **确认 Agent 工具可用**：Claude/OpenCode/Codex 需要当前运行时的子 Agent/Task 调用能力，Antigravity 需要 `invoke_subagent`；不可用时直接降级为 `solo`，报告 `Fallback: agent tool unavailable -> solo`。
-6. **运行时失败降级**：如果任何 Agent spawn 返回失败、`subagent_type` / `agent` / `agent_type` / `TypeName` 不可用、frontmatter/TOML 运行时解析失败或子 Agent 无法启动，停止继续 spawn，改用 `solo` 重新审查，并报告 `Fallback: spawn failed -> solo` 与失败的 agent 名；不要把部分成功的 Agent 结果当成 full/lean 结论。
+5. **确认 Agent 工具可用**：Claude/OpenCode/Codex 需要当前运行时的子 Agent/Task 调用能力，Antigravity 需要 `invoke_subagent`；不可用时直接降级为 `solo`，技术备注写 `Fallback: agent tool unavailable -> solo`。
+6. **运行时失败降级**：如果任何 Agent spawn 返回失败、`subagent_type` / `agent` / `agent_type` / `TypeName` 不可用、frontmatter/TOML 运行时解析失败或子 Agent 无法启动，停止继续 spawn，改用 `solo` 重新审查，技术备注写 `Fallback: spawn failed -> solo` 与失败的 agent 名；不要把部分成功的 Agent 结果当成 full/lean 结论。
 7. **确定实际模式**：请求模式与实际模式都写进报告末尾的技术备注行。
 
 ---
@@ -92,6 +92,7 @@ metadata: {"openclaw":{"source":"https://github.com/zenstory-ai/oh-story-claudec
 | 标点预检脚本 | `story-review/scripts/normalize-punctuation.js` |
 | AI句式预检脚本 | `story-review/scripts/check-ai-patterns.js` |
 | 作者习惯协议 | `story-review/references/author-memory.md` |
+| 作者习惯整理、超编与迁移 | `story-review/references/author-memory-maintenance.md` |
 | 作者习惯事务脚本 | `story-review/scripts/author_memory_commit.py` |
 
 ### 内置审查基准包（路径不可读时必用）
@@ -130,21 +131,6 @@ AI 味 / 禁用词 fallback 速查：
 - 起点：设定自洽、升级路径、长线期待、世界观承载力。
 - 知乎盐言：短篇钩子、反转密度、情绪兑现、信息差推进。
 
-### 传给子 Agent 的规则
-
-full/lean 模式下，主会话必须把“审查基准包摘要”直接写进每个 Agent prompt。**不要要求子 Agent 必须读取 `story-review/references/*` 才能完成任务**；如需补充，只读取本 Skill 的 `story-review/references/*`，最终遵守注入的 rubric 摘要和统一 Findings Schema。
-
-### 跨批审查落盘契约（所有模式）
-
-只要多章/整卷/整本审查被拆成两批及以上，full、lean、solo 都维护 **{项目根}/.story-review/state.md**：
-
-1. 首批确定本次完整审查范围和批次顺序。每批综合裁决后，用同目录临时文件 + rename 原子重写 state.md，不能只把结果留在对话里。
-2. state.md 只记录完整审查范围、已完成范围、下一批，以及“上一批未解决 findings 摘要”。摘要项保留 location、issue 和预计核查/兑现范围。
-3. 下一批开始前先读取 state.md，把未解决摘要注入 reviewer prompt；已解决或用户明确不处理的项不再继承，但须在本批输出中说明。
-4. 每个项目同时只维护一条跨批审查；若新一轮与 state.md 中未完成范围不同，先说明会丢弃的旧进度并征得用户确认，确认后在首批完成时覆盖。续接时 state.md 缺失、损坏或本批超出既定范围，应明确报告并停止，不猜测旧内容；非分批审查不创建它。
-
-**.story-review/** 只保存审查状态，不属于小说事实追踪；不得借此修改正文、设定、大纲或 `追踪/`。
-
 ---
 
 ## Phase 1：收集待审查内容
@@ -155,9 +141,7 @@ full/lean 模式下，主会话必须把“审查基准包摘要”直接写进
 2. **范围传递策略**：
    - 优先把文件路径、章节名、行号范围传给 reviewer，不要把整本或大量章节完整复制进每个 prompt。
    - 单文件或短片段可附 300-1200 字关键摘录。
-   - 多章/整卷/整本审查必须分批：按章节或文件组拆分，每批输出独立 findings，再综合。
-   - **跨批连续性（分批必做）**：审每一批前，先读 `追踪/伏笔.md` 中状态为 `已埋` 且计划回收章 ≤ 本批末章的当前行，再按需读取相关 `追踪/逐章记录/第NNN章.md` 查变更原因；同时读取涉及角色的独立快照，并按上方契约把 state.md 的上一批未解决 findings 摘要作为「继承的开放项」注入 reviewer / consistency-checker prompt。新发现但尚未登记的开放钩子先列为维护候选，收尾时必须有正文证据才能进入修订事务。
-   - **乱序/重叠审查提醒**：若已审过靠后的范围（如先审 300-400），之后审靠前的范围（200-300）时，只有当本批**新增/改动了一个开放项、且其预计兑现章落在已审过的靠后范围内**，才提醒用户「200-300 的改动可能影响已审的 300-400」，并让用户选择复审受影响章节 / 全量复审 / 仅记为待办——**默认记为待办，不盲目全量重跑**。无具体跨范围依赖时不提醒。
+   - 多章/整卷/整本审查必须分批：按章节或文件组拆分，每批输出独立 findings，再综合；分批前先完整读 [references/batch-review.md](references/batch-review.md)（跨批状态、连续性、乱序提醒）。
 3. **读取相关支撑材料**：正文、相关设定、角色档案、大纲、追踪/上下文、伏笔文件；缺失时在报告中标记证据不足。
 4. **识别目标平台并加载 rubric**：
    - 优先使用用户显式指定的平台。
@@ -176,24 +160,16 @@ full/lean 模式下，主会话必须把“审查基准包摘要”直接写进
    ```
    - 将 `ellipsis`、`double-hyphen`、`markdown-divider` 结果作为 `format` findings 合并进报告。`em-dash` 破折号只采用 `check-ai-patterns.js` 的语义改写建议（见下条）；`normalize-punctuation.js` 报的同一位置 `em-dash` 在合并时去重丢弃，避免同处出现「机械替换」与「按功能改写」两条相互冲突的 finding。另外人工检查标点节奏是否通篇句号化或随机堆砌，脚本不替代语气判断。
    - `check-ai-patterns.js` 的 findings 合并进 `prose`：severity=blocking 的类别一律按 S2（当前为 `not-is-comparison` / `em-dash` / `voice-contrast` / `negation-parade` / `reverse-not-is` / `trailer-ending` / `trailer-summary`），修法直接采用检测器输出的建议（删否定铺垫/反差腔/排比否定/章尾预告腔/章尾状态总结句，直接写后项或具体动作；破折号按功能改成动作/短句/逗号/冒号）。
-   - 其余 prose findings 统一按 S4：只指出读感风险，不替代人工判断；功能性写法标 `[需复核]` 并保留。完整类别和修法见 `anti-ai-writing.md`。
-   - `check-degeneration.js` 报告模型退化（逐字复读/截断/占位符/工程词泄漏），每条带 `severity: blocking|advisory`：blocking（复读/截断/tier1 工程词）作为 S1/S2 `prose` findings，修复建议是「重新生成该段，不是改写」；advisory（tier2 章节/歧义词）作为 S4。
-   - 这三个预检脚本只读；`story-review` **不修改正文、设定或大纲文件**，需要自动修复正文时建议转 `/story-deslop`。full / lean 模式只有下方「追踪文件维护」允许修改 `追踪/`；分批审查的所有模式都可按上方契约写 **.story-review/state.md**，solo 除该状态外不写项目内容。
+   - 其余 prose findings（advisory）统一按 S3：只指出读感风险，不替代人工判断；功能性写法标 `[需复核]` 并保留。完整类别和修法见 `anti-ai-writing.md`。
+   - `check-degeneration.js` 报告模型退化（逐字复读/截断/占位符/工程词泄漏），每条带 `severity: blocking|advisory`：blocking（复读/截断/tier1 工程词）作为 S1/S2 `prose` findings，修复建议是「重新生成该段，不是改写」；advisory（tier2 章节/歧义词）作为 S3。
+   - 这三个预检脚本只读；`story-review` **不修改正文、设定或大纲文件**，需要自动修复正文时建议转 `/story-deslop`。full / lean 模式只有下方「追踪文件维护」允许修改 `追踪/`；分批审查的所有模式都可按 batch-review.md 写 **.story-review/state.md**，solo 除该状态外不写项目内容。
    - 默认 `--quote-mode keep`，不把知乎盐言短篇的 `「」` 当作问题；只有项目明确指定引号风格时才检查对应转换建议。
 
-**story-explorer 预查询（可选）**。仅当 `Effective Mode` 仍为 `full`/`lean`、当前允许 spawn 且当前运行时的 Agent 工具可用时，才可在对应 canonical agent 目录下确认 `story-explorer` 已部署并 spawn；Antigravity 检查 `.agents/agents/story-explorer/agent.md`，用 `invoke_subagent` + `TypeName: "story-explorer"`。`solo` 或子代理递归保护场景下不得 spawn，只能直接读取/检索。Prompt 示例：
-
-```text
-项目目录：{dir}
-查询类型：setting_appearances
-查询参数：{审查涉及的设定关键词}
-```
-
 ---
 
 ## 统一 Findings Schema（所有模式必须使用）
 
-所有 reviewer（包括 solo）输出问题时必须使用统一结构，方便综合排序；它只在 reviewer 与综合裁决之间流转，给作者的报告按 Phase 4 模板转写。`location` 必须使用工具读取结果显示的原始文件行号；不要删除空行后重新编号。
+所有 reviewer（包括 solo）输出问题时必须使用统一结构，方便综合排序；它只在 reviewer 与综合裁决之间流转，给作者的报告按 Phase 4 或 solo 模板转写。`location` 必须使用工具读取结果显示的原始文件行号；不要删除空行后重新编号。
 
 对 `consistency` / `factual` / `causal` / `rule_boundary` 类 finding，`fix` 字段只写事实统一方向（例如“统一为左臂旧伤，并同步正文/设定中冲突处”或“需在 A/B 时间线中裁定一个来源”），不要写文学创作建议。
 
@@ -208,7 +184,7 @@ full/lean 模式下，主会话必须把“审查基准包摘要”直接写进
 
 严重度定义（与长篇写作、检测器同一刻度：S1/S2＝必须修，S3＝建议看，S4＝仅提示）：
 - **S1**：会破坏主线、角色动机、世界规则或读者信任，需优先修。
-- **S2**：明显影响章节效果、留存、节奏、人物可信度，建议本轮修。
+- **S2**：明显影响章节效果、留存、节奏、人物可信度，本轮要修。
 - **S3**：局部质量问题，如措辞、轻微格式、局部节奏，可排期修。
 - **S4**：建议项或风格微调，不阻塞发布。
 
@@ -216,255 +192,25 @@ full/lean 模式下，主会话必须把“审查基准包摘要”直接写进
 
 ## Phase 2：并行 Spawn Agent（full/lean 模式）
 
-使用当前运行时的 Agent 工具并行调用（Codex 原生子代理使用 `agent_type`，Claude Code 使用 `subagent_type`，OpenCode 使用 `subagent` 工具的 `agent` 参数，Antigravity 使用 `invoke_subagent` + 同名 `TypeName`；实际字段以当前 CLI 暴露的工具为准）。每个 Agent 不继承父对话上下文，prompt 必须自包含项目路径、审查范围、文件路径、必要摘录、审查基准包摘要、Rubric Source 和统一 Findings Schema。
-
-**调用规则**：执行 Phase 0 后，只有实际模式仍是 full/lean 时才 spawn。不要 spawn 缺失 Agent。
-
-**Agent 1: story-architect**（subagent_type: story-architect）
-- full/lean 均调用。
-- 审查视角：主题对齐、大纲结构、钩子/反转质量、范围控制、平台期待。
-- 提示指令：
-  ```
-  你是 story-architect，从故事架构层面审查以下内容。
-  你的任务是【找问题】，不是验证正确性。以最严苛的标准审视。
-  项目路径：{项目根}
-  审查范围：{文件路径/章节/必要摘录}
-  文风路径：{本书文风全文路径，无则写无}
-  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}
-  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}
-  Rubric Source: file | embedded fallback
-  相关文件路径：{设定/大纲/细纲文件路径}
-  继承的开放项（分批审查必填，无则写「无」）：{从 追踪/伏笔.md 提取的、预计回收章 ≤ 本批末章的已埋未回收钩子，连同上一批未解决 findings 摘要}
-  可选补充参考：本 Skill 的 `story-review/references/review-quality.md`、`story-review/references/plot-core-methods.md`；若不可读，不影响审查。
-  检查项：
-  1. 这一章是否推进了故事主题？
-  2. 大纲结构是否完整（钩子/爽点/悬念）？
-  3. 情绪节奏是否合理？
-  4. 钩子和反转设计质量如何？
-  5. 范围控制：有无角色/设定膨胀？
-  6. 剧情循环是否存在且可重复？（参照审查基准包摘要里的剧情循环原则）
-  7. 高潮场景是否用了蓄能→假胜→崩解结构？（参照审查基准包摘要里的高潮构建原则）
-  8. 伏笔密度、连载期待和结构信息量是否合理？（伏笔密度通常只作为 S4 结构风险，除非已造成理解混乱）
-  9. 按平台 rubric 或通用内容 rubric 逐项对照，标记 PASS/FAIL。
-  10. 继承的开放项里，本批本该兑现的钩子/伏笔是否落空？
-  11. 开头同质化（仅当本章是全书开篇/前 3 章）：开局切口是不是同题材的默认套路（穿越即退婚、系统绑定、末世第一天、开场即打脸等），能不能原样换到任意同类书？"有钩子/非天气开场"不等于不同质。对照 references/plot-core-methods.md「噱头分类与开篇流程」判断——能整体换到同类书=同质化（撞题材模板至少 S2；套路化但有具体人物/处境微差 S3）。
-  12. 结尾总结：章尾是总结/升华/复述式收尾（"就这样……""他终于明白……""这一夜注定……"），还是落在动作/画面/悬念上？检测器已判 blocking 的（`trailer-summary`）按上面「blocking 一律 S2」处理，不重复定级；检测器没覆盖的总结/升华/复述式收尾按影响定 S2/S3（改写走 /story-deslop Gate F，本 skill 只标问题不改写）。
-
-  输出格式：
-  VERDICT: APPROVE / CONCERNS / REJECT
-  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4。
-  INHERITED_ITEMS: 逐条列继承的开放项 + 已检查 / 未能检查；本批本该兑现却落空的列为 finding。
-  RECOMMENDATIONS: [修改建议]
-  ```
-
-**Agent 2: character-designer**（subagent_type: character-designer）
-- full 模式调用。
-- 审查视角：角色语言风格一致性、对话质量、人物弧线、关系推进。
-- 提示指令：
-  ```
-  你是 character-designer，从角色和对话层面审查以下内容。
-  你的任务是【找问题】，不是验证正确性。以最严苛的标准审视。
-  项目路径：{项目根}
-  审查范围：{文件路径/章节/必要摘录}
-  文风路径：{本书文风全文路径，无则写无}
-  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}
-  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}
-  Rubric Source: file | embedded fallback
-  相关角色文件：{角色设定文件路径}
-  可选补充参考：本 Skill 的 `story-review/references/character-relations.md`、`story-review/references/dialogue-mastery.md`；若不可读，不影响审查。
-  检查项：
-  1. 角色语言风格是否与语言风格档案一致？
-  2. 对话是否千篇一律或信息过满？
-  3. 人物弧线是否连贯？
-  4. 角色行为是否符合其动机？
-  5. 对话是否有潜台词和信息控制？
-  6. 爱情线好感度与 CP 行为是否匹配？（参照审查基准包摘要或本 Skill 的角色关系参考）
-  7. 好感度进度是否可感知？
-  8. 对话三症状（可选读 `story-review/references/dialogue-mastery.md` 自查项）：① 机械对话/问答式/句间无情绪承接；② 角色当「科普嘴」整段讲设定原理(Gate G 同样管台词)；③ 说话不分场合(高压/生死 beat 的玩笑、口头梗、插科打诨出戏)。命中按 S2/S3 报具体引用+改法。
-
-  输出格式：
-  VERDICT: APPROVE / CONCERNS / REJECT
-  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4。
-  RECOMMENDATIONS: [修改建议]
-  ```
-
-**Agent 3: narrative-writer**（subagent_type: narrative-writer）
-- full 模式调用。
-- 审查视角：AI味检测（含解释腔/上帝感/安排感=模式 8）、情绪烈度（够不够爽/会不会太保守）、格式合规、节奏均匀度、文字自然度。
-- 提示指令：
-  ```
-  你是 narrative-writer，从文字质量层面审查以下内容。
-  你的任务是【找问题】，不是验证正确性。以最严苛的标准审视。
-  项目路径：{项目根}
-  审查范围：{文件路径/章节/必要摘录}
-  文风路径：{本书文风全文路径，无则写无}
-  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}
-  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}
-  Rubric Source: file | embedded fallback
-  AI 味 / 禁用词摘要：{从 anti-ai-writing、banned-words 或内置 fallback 提取，必须内联}
-  可选补充参考：本 Skill 的 `story-review/references/anti-ai-writing.md`、`story-review/references/banned-words.md`、`story-review/references/review-quality.md`；若不可读，不影响审查。
-  检查项：
-  1. 是否存在禁用词/套话/陈词滥调，或“像/好像/仿佛/如同”式比喻成片堆叠？
-  2. 是否出现 AI 写作指纹、8 种 AI 写作模式（含模式 8 解释腔/上帝视角/安排感）或章末总结体？
-  3. 格式是否合规（按戏剧单元/镜头自然断段、无机械字数切分、无空行、对话独立成行、主语节奏自然）？
-  4. 标点节奏是否匹配语气/人物声线：是否通篇句号化、随机堆砌问号/感叹号，或残留 `……`/`——` 硬造停顿？本书已明确授权且有功能的停顿不因符号本身判错。
-  5. 是否出现“这五个字 / 短短四字 / 三个字一落 / 八个字砸下去”等正文内具体字数表达？若统计口径不明、未见机器核对结果或无叙事必要，标为问题并建议改成非具体数字表达。
-  6. 节奏是否均匀（有无连续多节无情绪变化）？
-  7. 是否存在删掉无损的任务卡点或流程细节？若只是水/局部节奏问题标 S3；明显拖垮主线推进标 S2。
-  8. 身体细节是否重复、无功能？按本书文风和叙事作用判断，不设单词次数硬线。
-  9. AI味分级（轻度/中度/重度）及证据。
-  10. 去 AI 补充复核：是否有作者解释总结/意义尾巴；是否连续堆精致戏剧反应短语；是否把已有手机/屏幕/公告/规则/证据载体改成叙述者解释；是否把任务卡点当成自然感或凑字数手段；是否机械删除了有功能的生活化/角色化比喻或短篇主观审判句。
-
-  输出格式：
-  VERDICT: APPROVE / CONCERNS / REJECT
-  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4；AI味级别写入 issue 或 category。
-  RECOMMENDATIONS: [修改建议]
-  ```
-
-**Agent 4: consistency-checker**（subagent_type: consistency-checker）
-- full/lean 均调用。
-- 审查视角：grep-first + 推理型一致性检测，输出 S1-S4 报告。
-- 提示指令：
-  ```
-  你是 consistency-checker，使用 grep-first + 推理型一致性审查检测事实矛盾。
-  你的任务是【找事实矛盾、状态断线和需要推理才能发现的设定逻辑冲突】，不做创作评判，不评价文学质量，不输出创作修改建议。
-  项目路径：{项目根}
-  审查范围：{文件路径/章节/必要摘录}
-  已知角色：{从设定文件提取角色列表}
-  继承的开放项（分批审查必填，无则写「无」）：{从 追踪/伏笔.md 提取的、预计回收章 ≤ 本批末章的已埋未回收伏笔，连同上一批未解决 findings 摘要}
-  文风路径：{本书文风全文路径，无则写无}
-  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}
-  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}
-  Rubric Source: file | embedded fallback
-  可选补充参考：本 Skill 的 `story-review/references/review-quality.md`；若不可读，不影响事实冲突扫描。
-  检查项：
-  1. 角色属性是否前后一致？
-  2. 世界规则是否被违反？
-  3. 伏笔状态是否前后一致（已埋/计划回收/已回收/断线）？
-  4. 时间线是否自洽？
-  5. 术语、身份、地点、能力边界是否前后一致？
-  6. 继承的开放项里，本批本该回收的伏笔是否仍悬空？
-
-  输出格式：
-  VERDICT: APPROVE / CONCERNS / REJECT
-  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4；category 只能使用 consistency / factual / format / causal / rule_boundary。
-  INHERITED_ITEMS: 逐条列继承的开放项 + 已检查 / 未能检查；本批新发现、不在 伏笔.md 的开放钩子单列，供主会话回写 追踪/伏笔.md。
-  FACTUAL_RECONCILIATION: [仅列需统一的事实来源或需人工裁决项，不写文学创作建议]
-  REASONING_CHAINS: [仅列推理型 finding 的前提/规则 -> 触发事件 -> 矛盾点 -> 需裁决问题]
-  ```
+执行 Phase 0 后实际模式仍是 full/lean 时，读 [references/agent-prompts.md](references/agent-prompts.md) 按其中的调用规则与四个 prompt 并行 spawn，综合裁决与报告模板也在其中；不 spawn 缺失的 Agent。每个 Agent 不继承父对话上下文，prompt 自包含路径、范围与统一 Findings Schema。
 
----
+## Phase 3：综合裁决（full / lean 模式）
 
-## Phase 3：综合裁决
-
-1. 收集实际执行的 reviewer VERDICT 和 FINDINGS。
-2. 合并去重：按 `severity` 排序（S1 > S2 > S3 > S4），同级内按影响范围排序。
-3. **可选事实核查**：如果审查内容涉及需要验证的外部事实（历史年代、地理方位、职业细节等），只有在 `Effective Mode` 仍为 `full`/`lean`、当前不是子 Agent、当前运行时的 Agent 工具可用且对应 canonical agent 目录下的 `story-researcher` 已部署时，才可额外 spawn；Antigravity 检查 `.agents/agents/story-researcher/agent.md`，用 `invoke_subagent` + `TypeName: "story-researcher"`。`solo`、missing/malformed/stale/spawn failed 降级或子代理递归保护场景下不得 spawn，只能在报告中标记“需人工事实核查”。
-4. **分歧呈现**：如果 reviewer 间有冲突意见，明确呈现分歧让用户裁决；不要自动妥协。
-5. 按「报告面向作者」输出综合审查报告：开头说明审查方式与范围，证据不足项写成作者能补的材料，执行路径只进技术备注行。
-
----
+收齐 reviewer 结果后按 agent-prompts.md「综合裁决」合并、去重、呈现分歧。
 
 ## Phase 4：输出报告（full / lean 模式）
 
-只有实际模式确实为 `full` 或 `lean` 时才使用本模板；如果 Phase 0 或运行时失败导致降级 `solo`，必须改用 solo 模式模板。lean 排除的视角写进「这次怎么审的」；full/lean 必需 reviewer 缺失或 spawn 失败时降级 solo，不在本模板里标「未看」后继续综合。
-
-<!-- author-report -->
-```md
-=== 《{书名}》{审查范围}审查 ===
-这次怎么审的：{结构、人物、文字、设定一致性四个视角分头看 | 精简审：结构和设定一致性两个视角}，按{番茄 | 起点 | 知乎盐言 | 通用网文}的标准。
-
-总体判断：{可以发 | 改完下面几处再发 | 这一章需要重写}——{一句话理由，用读者感受说}
-
-## 必须改（{n} 处）
-1. 第{N}章「{原文引用}」
-   问题：{读者会怎么想、哪里读不通}
-   建议：{具体改法}
-
-## 建议改（{n} 处）
-{同上格式}
-
-## 可以不改（{n} 处）
-{一行一条：位置 + 问题 + 改法；风格微调也放这里}
-
-## 需要你决定
-{审稿视角有分歧、或事实需要你裁定时，写成问题 + 选项 + 我的建议，例如「第12章写左臂受伤、第15章写右臂，统一成哪边？建议左臂（第12章交代了伤的来历）」；没有就写"无"}
-
-## 没法判断的地方
-{缺哪份设定或大纲导致没法核对、需要人工查证的外部事实；没有就写"无"}
-
-## 下一批接着核对
-{仅分批审查：留到下一批回头看的问题 + 预计在哪几章兑现；否则删掉本节}
-
-下一步：{例如「说"改第12章"，我按必须改的几处动手」「AI 味集中的段落可以说"去 AI 味"」}
-技术备注：Mode {full | lean}→{full | lean} · Fallback none · Rubric {…} ({file | embedded})
-```
+实际模式确为 full/lean 时用 agent-prompts.md 的报告模板；降级 solo 时改用 solo.md 模板。
 
 ---
 
 ## solo 模式
 
-不 spawn Agent。先按 Phase 1 第 4 步识别目标平台并加载对应 rubric；即使是 solo，也必须用平台 rubric、`story-review/references/quality-rubric.md` 或内置审查基准包校准判断。
-
-solo 必须执行基础检查：
-1. 格式合规性检查：按戏剧单元/画面分段而非机械按字数切分（偶发稍长的完整推理、氛围或情绪链不算违规，通篇同阈值切段或碎成提纲才算）；段首建立主语、段中用代词或省略，连续无必要重复同一角色名才算主语过密；无段间空行；对话独立成行；具体数字须确认统计正确且有叙事必要。
-2. 简单的设定一致性 grep（角色名、属性、关键设定、伏笔关键词）+ 推理型一致性检查（规则边界、设定层级、跨章因果链、可滥用漏洞、代价一致性）。
-3. AI 味与禁用词检查（优先读取 `story-review/references/banned-words.md` 与 `story-review/references/anti-ai-writing.md`，不可读时使用内置 AI 味 / 禁用词 fallback 速查）。
-4. 通用网文内容评分（优先读取 `story-review/references/quality-rubric.md`，不可读时使用内置通用网文内容 rubric）。
-5. 按统一 Findings Schema 整理问题，再按下方模板写给作者。
-
-### solo 模式输出格式
-
-<!-- author-report -->
-```md
-=== 《{书名}》{审查范围}审查（单人审）===
-这次怎么审的：我一个人审{；原因一句话，如"审稿助手还没装，运行 /story-setup 后可以四个视角审"}，按{番茄 | 起点 | 知乎盐言 | 通用网文}的标准。
-
-总体判断：{可以发 | 改完下面几处再发 | 这一章需要重写}——{一句话理由}
-
-## 格式与设定
-- 分段与人名节奏：{没问题 | 第N章第M段起……}
-- 空行与对话换行：{没问题 | ……}
-- 具体数字：{没问题 | 第N章「……」对不上或没必要}
-- 前后矛盾：{没发现 | 第N章「……」与第M章「……」矛盾}
-- 因果和规则漏洞：{没发现 | ……}
-
-## 必须改（{n} 处）
-1. 第{N}章「{原文引用}」
-   问题：{读者会怎么想、哪里读不通}
-   建议：{具体改法}
-
-## 建议改（{n} 处）
-{同上格式}
-
-## 可以不改（{n} 处）
-{一行一条}
-
-## 需要你决定
-{问题 + 选项 + 我的建议；没有就写"无"}
-
-## 没法判断的地方
-{缺哪份设定或大纲导致没法核对、需要人工查证的外部事实；没有就写"无"}
-
-## 下一批接着核对
-{仅分批审查填写；否则删掉本节}
-
-下一步：{一句话}
-技术备注：Mode {full | lean | solo}→solo · Fallback {…} · Rubric {…} ({file | embedded})
-```
-
----
-
-## 追踪文件维护（长篇工程，审查收尾时执行）
-
-新追踪协议只有一个写入口：本 skill 的 `scripts/tracking_commit.py`；完整事务字段和命令见 `references/tracking-transaction.md`。**full / lean 模式只允许通过该工具修改 `追踪/`；solo 模式不修改任何 `追踪/` 文件。**不得直接 Edit/Write/追加 `伏笔.md`、角色快照、时间线视图、摘要或 `上下文.md`。
+降级或指定 solo 时读 [references/solo.md](references/solo.md)，按其中流程与输出格式执行。
 
-1. **先检查状态**：执行 `tracking_commit.py check --project {项目根}`，确认 `_tracking-state.json` 与全部派生视图一致。失败时重跑产生当前目标状态的原事务，不得猜测、手改 Markdown 或另造事务覆盖。
-2. **判定是否需要修订**：只有正文证据表明现有追踪事实错误或缺失时才维护。过期伏笔、漏登记开放钩子、角色当前状态、客观时间线、读者认知都归入其证据所在章的 `mode=revision` 事务。普通审查意见和未来写作建议不进追踪。
-3. **构造完整同章事务**：保留该章原有紧凑增量中仍成立的字段，只修改有证据的变化；核心角色变化同时提交截至当前最后已写章的完整 `character_snapshots`。伏笔对同一 ID `upsert` 当前状态，不增加重复行；时间线同时提交客观事实、读者当前认知和实际揭示状态。
-4. **提交并复检**：执行 `tracking_commit.py commit`，再执行 `check`。确认逐章记录规范且未超限、`上下文.md` 恰好固定 7 栏且 ≤12288 字节、作者/读者时间线及全部派生视图与 state 一致。
+## 追踪文件维护
 
-例如审查 demo 第 10 章时，若正文明确显示周薄森说专业重拍版“缺了灵魂”、张耀祖拍板继续用江晨手机原版，修订事务可以把该结果写进客观事实和读者已知；钟嘉嘉“只猜对了一半”背后的培养安排如果正文尚未揭示，只能留在作者真相，不能写入读者视图。
+长篇工程且 full/lean 审查收尾时读 [references/review-tracking.md](references/review-tracking.md)。
 
 ## 流程衔接
 

package/lib/oh-story/skills/story-review/references/agent-prompts.md

@@ -0,0 +1,184 @@
+# story-review：full/lean 模式派子代理与综合
+
+只有实际模式仍是 full/lean 时才读本文件。
+
+使用当前运行时的 Agent 工具并行调用（Codex 原生子代理使用 `agent_type`，Claude Code 使用 `subagent_type`，OpenCode 使用 `subagent` 工具的 `agent` 参数，Antigravity 使用 `invoke_subagent` + 同名 `TypeName`；实际字段以当前 CLI 暴露的工具为准）。每个 Agent 不继承父对话上下文，prompt 必须自包含项目路径、审查范围、文件路径、必要摘录和统一 Findings Schema。审稿视角的三个 prompt 还要内联审查基准包摘要与 Rubric Source，不要求子 Agent 必须读 `story-review/references/*` 才能完成任务（如需补充只读本 Skill 的 references）；consistency-checker 例外，它只核对事实，按自己的检查项审，不带审查基准包。所有 reviewer 只读：不改任何文件，只输出结果。
+
+**调用规则**：执行 Phase 0 后，只有实际模式仍是 full/lean 时才 spawn。不要 spawn 缺失 Agent。
+
+**story-explorer 预查询（可选）**。仅当 `Effective Mode` 仍为 `full`/`lean`、当前允许 spawn 且当前运行时的 Agent 工具可用时，才可在对应 canonical agent 目录下确认 `story-explorer` 已部署并 spawn；Antigravity 检查 `.agents/agents/story-explorer/agent.md`，用 `invoke_subagent` + `TypeName: "story-explorer"`。`solo` 或子代理递归保护场景下不得 spawn，只能直接读取/检索。Prompt 示例：
+
+```text
+项目目录：{dir}
+查询类型：setting_appearances
+查询参数：{审查涉及的设定关键词}
+```
+
+**Agent 1: story-architect**（subagent_type: story-architect）
+- full/lean 均调用。
+- 审查视角：主题对齐、大纲结构、钩子/反转质量、范围控制、平台期待。
+- 提示指令：
+  ```
+  你是 story-architect，从故事架构层面审查以下内容。
+  你的任务是【找问题】，不是验证正确性。以最严苛的标准审视。
+  项目路径：{项目根}
+  审查范围：{文件路径/章节/必要摘录}
+  文风路径：{本书文风全文路径，无则写无}
+  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}
+  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}
+  Rubric Source: file | embedded fallback
+  相关文件路径：{设定/大纲/细纲文件路径}
+  继承的开放项（分批审查必填，无则写「无」）：{从 追踪/伏笔.md 提取的、预计回收章 ≤ 本批末章的已埋未回收钩子，连同上一批未解决 findings 摘要}
+  检查项：
+  1. 这一章是否推进了故事主题？
+  2. 大纲结构是否完整（钩子/爽点/悬念）？
+  3. 情绪节奏是否合理？
+  4. 钩子和反转设计质量如何？
+  5. 范围控制：有无角色/设定膨胀？
+  6. 剧情循环是否存在且可重复？（参照审查基准包摘要里的剧情循环原则）
+  7. 高潮场景是否用了蓄能→假胜→崩解结构？（参照审查基准包摘要里的高潮构建原则）
+  8. 伏笔密度、连载期待和结构信息量是否合理？（伏笔密度通常只作为 S4 结构风险，除非已造成理解混乱）
+  9. 按平台 rubric 或通用内容 rubric 逐项对照，标记 PASS/FAIL。
+  10. 继承的开放项里，本批本该兑现的钩子/伏笔是否落空？
+  11. 开头同质化（仅当本章是全书开篇/前 3 章）：开局切口是不是同题材的默认套路（穿越即退婚、系统绑定、末世第一天、开场即打脸等），能不能原样换到任意同类书？"有钩子/非天气开场"不等于不同质。对照 `story-review/references/plot-core-methods.md`「噱头分类与开篇流程」判断——能整体换到同类书=同质化（撞题材模板至少 S2；套路化但有具体人物/处境微差 S3）。
+  12. 结尾总结：章尾是总结/升华/复述式收尾（"就这样……""他终于明白……""这一夜注定……"），还是落在动作/画面/悬念上？检测器已判 blocking 的（`trailer-summary`）按上面「blocking 一律 S2」处理，不重复定级；检测器没覆盖的总结/升华/复述式收尾按影响定 S2/S3（改写走 /story-deslop：章尾预告与章尾状态总结归 Gate F，其余 blocking 并入 Gate B；本 skill 只标问题不改写）。
+
+  输出格式：
+  VERDICT: APPROVE / CONCERNS / REJECT
+  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4。
+  INHERITED_ITEMS: 逐条列继承的开放项 + 已检查 / 未能检查；本批本该兑现却落空的列为 finding。
+  RECOMMENDATIONS: [修改建议]
+  ```
+
+**Agent 2: character-designer**（subagent_type: character-designer）
+- full 模式调用。
+- 审查视角：角色语言风格一致性、对话质量、人物弧线、关系推进。
+- 提示指令：
+  ```
+  你是 character-designer，从角色和对话层面审查以下内容。
+  你的任务是【找问题】，不是验证正确性。以最严苛的标准审视。
+  项目路径：{项目根}
+  审查范围：{文件路径/章节/必要摘录}
+  文风路径：{本书文风全文路径，无则写无}
+  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}
+  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}
+  Rubric Source: file | embedded fallback
+  相关角色文件：{角色设定文件路径}
+  检查项：
+  1. 角色语言风格是否与语言风格档案一致？
+  2. 对话是否千篇一律或信息过满？
+  3. 人物弧线是否连贯？
+  4. 角色行为是否符合其动机？
+  5. 对话是否有潜台词和信息控制？
+  6. 爱情线好感度与 CP 行为是否匹配？（参照审查基准包摘要或本 Skill 的角色关系参考）
+  7. 好感度进度是否可感知？
+  8. 对话三症状（可选读 `story-review/references/dialogue-mastery.md` 自查项）：① 机械对话/问答式/句间无情绪承接；② 角色当「科普嘴」整段讲设定原理(Gate G 同样管台词)；③ 说话不分场合(高压/生死 beat 的玩笑、口头梗、插科打诨出戏)。命中按 S2/S3 报具体引用+改法。
+
+  输出格式：
+  VERDICT: APPROVE / CONCERNS / REJECT
+  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4。
+  RECOMMENDATIONS: [修改建议]
+  ```
+
+**Agent 3: narrative-writer**（subagent_type: narrative-writer）
+- full 模式调用。
+- 审查视角：AI味检测（含解释腔/上帝感/安排感=模式 8）、情绪烈度（够不够爽/会不会太保守）、格式合规、节奏均匀度、文字自然度。
+- 提示指令：
+  ```
+  你是 narrative-writer，从文字质量层面审查以下内容。
+  你的任务是【找问题】，不是验证正确性。以最严苛的标准审视。
+  只读审查：不改任何文件（含正文），只输出下方 VERDICT / FINDINGS / RECOMMENDATIONS。
+  项目路径：{项目根}
+  审查范围：{文件路径/章节/必要摘录}
+  文风路径：{本书文风全文路径，无则写无}
+  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}
+  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}
+  Rubric Source: file | embedded fallback
+  去味判据：按你读取表的 anti-ai-writing、banned-words、deslop-gates 审（审查任务照表读），这里不摘抄
+  检查项：
+  1. 是否存在禁用词/套话/陈词滥调，或“像/好像/仿佛/如同”式比喻成片堆叠？
+  2. 是否出现 AI 写作指纹、10 种 AI 写作模式（含模式 8 解释腔/上帝视角/安排感）或章末总结体？
+  3. 格式是否合规（按戏剧单元/镜头自然断段、无机械字数切分、无空行、对话独立成行、主语节奏自然）？
+  4. 标点节奏是否匹配语气/人物声线：是否通篇句号化、随机堆砌问号/感叹号，或残留 `……`/`——` 硬造停顿？本书已明确授权且有功能的停顿不因符号本身判错。
+  5. 是否出现“这五个字 / 短短四字 / 三个字一落 / 八个字砸下去”等正文内具体字数表达？若统计口径不明、未见机器核对结果或无叙事必要，标为问题并建议改成非具体数字表达。
+  6. 节奏是否均匀（有无连续多节无情绪变化）？
+  7. 是否存在删掉无损的任务卡点或流程细节？若只是水/局部节奏问题标 S3；明显拖垮主线推进标 S2。
+  8. 身体细节是否重复、无功能？按本书文风和叙事作用判断，不设单词次数硬线。
+  9. AI味分级（轻度/中度/重度）及证据。
+  10. 去 AI 补充复核：是否有作者解释总结/意义尾巴；是否连续堆精致戏剧反应短语；是否把已有手机/屏幕/公告/规则/证据载体改成叙述者解释；是否把任务卡点当成自然感或凑字数手段；是否机械删除了有功能的生活化/角色化比喻或短篇主观审判句。
+
+  输出格式：
+  VERDICT: APPROVE / CONCERNS / REJECT
+  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4；AI味级别写入 issue 或 category。
+  RECOMMENDATIONS: [修改建议]
+  ```
+
+**Agent 4: consistency-checker**（subagent_type: consistency-checker）
+- full/lean 均调用。
+- 审查视角：grep-first + 推理型一致性检测，输出 S1-S4 报告。
+- 提示指令：
+  ```
+  你是 consistency-checker，使用 grep-first + 推理型一致性审查检测事实矛盾。
+  你的任务是【找事实矛盾、状态断线和需要推理才能发现的设定逻辑冲突】，不做创作评判，不评价文学质量，不输出创作修改建议。
+  项目路径：{项目根}
+  审查范围：{文件路径/章节/必要摘录}
+  已知角色：{从设定文件提取角色列表}
+  继承的开放项（分批审查必填，无则写「无」）：{从 追踪/伏笔.md 提取的、预计回收章 ≤ 本批末章的已埋未回收伏笔，连同上一批未解决 findings 摘要}
+  检查项：
+  1. 角色属性是否前后一致？
+  2. 世界规则是否被违反？
+  3. 伏笔状态是否前后一致（已埋/计划回收/已回收/断线）？
+  4. 时间线是否自洽？
+  5. 术语、身份、地点、能力边界是否前后一致？
+  6. 继承的开放项里，本批本该回收的伏笔是否仍悬空？
+
+  输出格式：
+  VERDICT: APPROVE / CONCERNS / REJECT
+  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4；category 只能使用 consistency / factual / format / causal / rule_boundary。
+  INHERITED_ITEMS: 逐条列继承的开放项 + 已检查 / 未能检查；本批新发现、不在 伏笔.md 的开放钩子单列，供主会话回写 追踪/伏笔.md。
+  FACTUAL_RECONCILIATION: [仅列需统一的事实来源或需人工裁决项，不写文学创作建议]
+  REASONING_CHAINS: [仅列推理型 finding 的前提/规则 -> 触发事件 -> 矛盾点 -> 需裁决问题]
+  ```
+
+## 综合裁决
+
+1. 收集实际执行的 reviewer VERDICT 和 FINDINGS。
+2. 合并去重：按 `severity` 排序（S1 > S2 > S3 > S4），同级内按影响范围排序。
+3. **可选事实核查**：如果审查内容涉及需要验证的外部事实（历史年代、地理方位、职业细节等），只有在 `Effective Mode` 仍为 `full`/`lean`、当前不是子 Agent、当前运行时的 Agent 工具可用且对应 canonical agent 目录下的 `story-researcher` 已部署时，才可额外 spawn；Antigravity 检查 `.agents/agents/story-researcher/agent.md`，用 `invoke_subagent` + `TypeName: "story-researcher"`。`solo`、missing/malformed/stale/spawn failed 降级或子代理递归保护场景下不得 spawn，只能在报告中标记“需人工事实核查”。
+4. **分歧呈现**：如果 reviewer 间有冲突意见，明确呈现分歧让用户裁决；不要自动妥协。
+5. 按 SKILL.md「报告面向作者」输出综合审查报告：开头说明审查方式与范围，证据不足项写成作者能补的材料，执行路径只进技术备注行。
+
+## 报告模板
+
+只有实际模式确实为 `full` 或 `lean` 时才使用本模板；如果 Phase 0 或运行时失败导致降级 `solo`，必须改用 solo 模式模板。lean 排除的视角写进「这次怎么审的」；full/lean 必需 reviewer 缺失或 spawn 失败时降级 solo，不在本模板里标「未看」后继续综合。
+
+<!-- author-report -->
+```md
+=== 《{书名}》{审查范围}审查 ===
+这次怎么审的：{结构、人物、文字、设定一致性四个视角分头看 | 精简审：结构和设定一致性两个视角}，按{番茄 | 起点 | 知乎盐言 | 通用网文}的标准。
+
+总体判断：{可以发 | 改完下面几处再发 | 这一章需要重写}——{一句话理由，用读者感受说}
+
+## 必须改（{n} 处）
+1. 第{N}章「{原文引用}」
+   问题：{读者会怎么想、哪里读不通}
+   建议：{具体改法}
+
+## 建议改（{n} 处）
+{同上格式}
+
+## 可以不改（{n} 处）
+{一行一条：位置 + 问题 + 改法；风格微调也放这里}
+
+## 需要你决定
+{审稿视角有分歧、或事实需要你裁定时，写成问题 + 选项 + 我的建议，例如「第12章写左臂受伤、第15章写右臂，统一成哪边？建议左臂（第12章交代了伤的来历）」；没有就写"无"}
+
+## 没法判断的地方
+{缺哪份设定或大纲导致没法核对、需要人工查证的外部事实；没有就写"无"}
+
+## 下一批接着核对
+{仅分批审查：留到下一批回头看的问题 + 预计在哪几章兑现；否则删掉本节}
+
+下一步：{例如「说"改第12章"，我按必须改的几处动手」「AI 味集中的段落可以说"去 AI 味"」}
+技术备注：Mode {full | lean}→{full | lean} · Fallback none · Rubric {…} ({file | embedded})
+```

package/lib/oh-story/skills/story-review/references/anti-ai-writing.md

@@ -285,7 +285,7 @@ AI 喜欢把事情凑成三个以显"完整"。-> 砍到只剩最有力的一条
 - 剧透式点破潜台词：「那点笑她看得分明」「谁都看得出他在撒谎」-> 把藏着的挑明了。留着别点破。
 - 定性比喻/盖棺句：「像在宣判一件早已定好的事」「像看一件死物」-> 比喻在替角色下定论。非角色此刻强烈主观感受就删；要留也只能是她带偏见的瞬间感觉，不是客观断言。
 
-自检：每句问一遍——这是"角色在经历"，还是"作者在讲解/安排"？凡作者跳出来讲，删，或改成角色视角内的呈现。根治办法是锁定深度限知视角（见 writing-craft.md「视角姿态：深度限知」），镜头钉死在角色身体里，作者就没位置跳出来了。
+自检：每句问一遍——这是"角色在经历"，还是"作者在讲解/安排"？凡作者跳出来讲，删，或改成角色视角内的呈现。根治办法是锁定深度限知视角：只写视角人物此刻看得见、听得见、想得到的，镜头钉死在角色身体里，作者就没位置跳出来了。
 
 改法优先级：先删或原位替换污染句，不在段尾另补“人味”尾巴。需要补信息时，把原来的总结/动机/评价句改成角色当下能碰到的问题、手续、回信、付款、门外动静等具体压力；已有手机/屏幕/公告/门牌/表单等信息，优先作为角色看见的场内载体保留，不要转写成叙述者解释。具体载体跟剧情走，不套固定清单。