/story-review

name: story-review
version: 1.1.1
description: "多视角对抗式审查。full/lean 模式在已部署 reviewer agents 时并行 spawn；缺失/异常 agents 或 spawn 失败时自动降级 solo，参考文件不可读时使用内置 rubric fallback。触发方式：/story-review、/审查、「审查一下」「帮我审一下」。"
metadata: {"openclaw":{"source":"https://github.com/zenstory-ai/oh-story-claudecode"}}

story-review：多视角对抗式审查

> Spawn 版本提示（不阻断 spawn）：先读取项目根 `.story-deployed` 的 `agents_version`。与本版 `agents_version: 42` 不一致时（标记缺失、字段缺失/非整数、小于或大于 42）**照常按当前宿主角色来源检查并 spawn**；同时在「这次怎么审的」里用一句白话提示作者「审稿助手是旧版，运行 /story-setup（ZCode 先更新插件）后新开会话」，`Notice: agents bundle 版本不匹配（项目 {N}，本版 42）` 原文写进技术备注行；大于 42 时额外提示先更新 oh-story-claudecode，不要用本地旧版 setup 降级覆盖。版本提示本身不触发降级；文件缺失或异常、工具不可用、递归限制或调用失败按 Phase 0 处理，技术备注写 `Fallback: ... -> solo`。

你负责协调审查，找出小说的结构、角色、文字与设定问题，给出有原文依据的修改建议。

**执行铁律：审查是找问题，不是验证正确性。**

**文风裁决**：先读 [references/style-resolution.md](references/style-resolution.md)，加载本书文风，复用调用方的 `style_resolution` 与作者偏好；单独调用时按当前请求与本书文风裁决。同一裁决交给后续执行者。

作者偏好边界

只接收调用方已有的作者偏好，不查询或记录作者记忆；独立调用时不加载记忆文件。偏好只能帮助解释意图和组织报告，不能降低 rubric 严重度、把事实冲突判为无问题或跳过平台门禁；当前请求仍优先。

---

Phase 0：预检与降级（必须先执行）

1. **确定请求模式**：解析用户输入中的 `full`（默认，优先 spawn 全部 4 个 Agent）、`lean`（优先 spawn `story-architect` + `consistency-checker`）、`solo`（不 spawn Agent，由当前会话执行基础审查）。 2. **确认是否允许 spawn**：如果当前已经在子代理/Agent 内执行，不再递归 spawn，直接降级为 `solo`。 3. **识别当前宿主的角色来源**：ZCode 支持插件子代理，检查当前已启用插件注册的同名角色，不要求 `.zcode/agents/`。其他宿主按下一步查本端目录；不因宿主名、部署标记包含 zcode 或其他端目录存在而降级。 4. **检查核心 Agent 可用状态**（仅查当前宿主来源）：

• Claude Code `.claude/agents/`、OpenCode `.opencode/agents/`、Codex `.codex/agents/`、Antigravity `.agents/agents/`；ZCode 查注册角色的定义，不拿项目文件存在性代替运行时注册
• full 必需 agent：`story-architect`、`character-designer`、`narrative-writer`、`consistency-checker`
• lean 必需 agent：`story-architect`、`consistency-checker`
• 对每个必需 Agent：
• **Claude Code agent（`.claude/agents/`）**：读取 frontmatter，确认 `name:` 与 subagent_type 完全一致；frontmatter 缺失、不可解析或 name 不匹配时视为 malformed agent。
• **OpenCode agent（`.opencode/agents/`）**：文件名即 agent 名（OpenCode 不要求在 frontmatter 中写 `name:`），读取 frontmatter 确认 `mode: subagent` 和 `permissions:` 规则列表存在且可解析即可（2.x 用复数 `permissions:`，旧版单数 `permission:` 视为待重新部署）；frontmatter 缺失或不可解析视为 malformed。
• **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。
• **ZCode plugin agent**：注册名与目标角色一致；可读定义须有可解析的 `name`、`description` 和正文。定义不可直接读时以运行时注册为准，不扫描其他端文件。
• 任一必需角色缺失或 malformed 时不尝试派发，降级 `solo`；白话说明助手缺失或损坏，并建议当前宿主重部署（ZCode 更新/启用 oh-story 插件后新开会话）。`missing agents -> solo` / `malformed agents -> solo` 与问题角色/文件写进技术备注 Fallback、Files 两栏。

5. **确认 Agent 工具可用**：Claude/OpenCode/Codex 需要当前运行时的子 Agent/Task 工具，Antigravity 需要 `invoke_subagent`，ZCode 用 `Agent` 按当前 schema 派发注册角色；不可用时降级 `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. **确定实际模式**：请求模式与实际模式都写进报告末尾的技术备注行。

---

审查基准与参考资料规则（必须遵守）

参考文件补充审查标准；不可读时使用下方内置基准包。

报告面向作者（必须遵守）

报告写给作者：审了什么、哪里要改、为什么（用读者感受和故事后果说，附原文引用）、要作者拍板的事、下一步。reviewer 名、S1–S4、Gate、检测器类别名、脚本名、PASS/FAIL、文件字段名不进正文；位置写「第 N 章「引文」」或「第 N 章第 M 段」。优先级换成白话（小节标题照模板）：S1、S2 → **必须改**，S3 → **建议改**，S4 → **可以不改**。执行路径只写在报告最后一行，格式固定：

技术备注：Mode {请求}→{实际} · Fallback {none | project custom agents unavailable -> solo | missing agents -> solo | malformed agents -> solo | agent tool unavailable -> solo | spawn failed -> solo | subagent recursion guard -> solo} · Rubric {fanqie | qidian | zhihu | generic} ({file | embedded})[ · Files {缺失或异常的 agent 文件}][ · Notice {版本不匹配原文}]

参考资料解析顺序

可读取参考文件时，按以下顺序尝试，第一个命中即用： 1. `{项目根}/.claude/skills/{规范路径}`（Claude Code 项目内安装） 2. `{项目根}/.opencode/skills/{规范路径}`（OpenCode 项目内安装） 3. `{项目根}/.codex/skills/{规范路径}`（Codex 项目内安装） 4. `{项目根}/.zcode/skills/{规范路径}`（ZCode 项目内安装） 5. `{项目根}/skills/{规范路径}`（OpenClaw / Reasonix / generic 部署，也是本仓库开发环境） 6. `{项目根}/.agents/skills/{规范路径}`（Antigravity 项目内真实 skill root；Codex / Reasonix 也可能扫描此目录或其 symlink） 7. 当前运行时加载本 skill 的目录，或其可访问的全局 skill 搜索路径中同名 `{skill-name}/...` 目录

> 靠前几层不存在属正常，命中第一个存在层即用；不要手工把 `references/` 复制进 `.codex/skills/`。

规范路径如下；禁止只写裸文件名，禁止跨 skill 误读其他 skill 的 references：

| 用途 | 规范路径 | |---|---| | 通用内容评分 rubric | `story-review/references/quality-rubric.md` | | 去 AI 味方法 | `story-review/references/expression.md` · `story-review/references/narrative-focus.md` · `story-review/references/story-logic.md` | | 词句信号索引 | `story-review/references/banned-words.md` | | 平台 rubric | `story-review/references/rubrics/{fanqie,qidian,zhihu}.md` | | 标点预检脚本 | `story-review/scripts/normalize-punctuation.js` | | AI句式预检脚本 | `story-review/scripts/check-ai-patterns.js` |

内置审查基准包（路径不可读时必用）

如果上述参考文件在当前项目中不可读，**不要把审查降级为无 rubric，也不要在报告里说“无法加载具体 rubric”后停止使用标准**。必须使用本节内置基准包，技术备注行的 Rubric 来源写 `embedded`。

通用网文内容 rubric：

• 核心卖点：本章是否围绕明确卖点推进；看不出卖点至少 S2。
• 冲突推进：本章是否有阻碍、选择、代价或关系变化；只解释/闲聊/总结至少 S2。
• 任务卡点：角色办事被卡住时，是否卡出信息、关系、代价、选择或伏笔变化；卡点只剩流程细节、删掉不影响故事至少 S3。
• 情绪曲线：是否有铺垫、升温、释放或反转；情绪平直或突兀至少 S2/S3。
• 钩子与期待：开头或结尾是否制造后续问题；没有悬念或未完成期待至少 S2。
• 开头新鲜度（仅开篇/前 3 章）：开局是否有具体人物/处境切口而非同题材默认套路；套路化开局即使有钩子也至少 S3，整体撞同题材模板 S2。
• 角色动机：行为是否符合目标、性格、处境和关系压力；为剧情服务而失真是 S1/S2。
• 对话质量：是否有潜台词、信息控制、角色差异；说明书式对话至少 S2。
• 设定一致性：不违背已写规则、时间线、角色属性；明确事实冲突通常 S1。
• 文字自然度：具体、可感、动作承载信息；AI 腔、陈词滥调、总结体按影响定 S2/S3。
• 句长节奏：按本书文风、语义承接与场景功能判断；机械碎句、动作清单或臃肿长句按影响定 S3/S2。
• 标点节奏：标点是否服务语气/人物声线；通篇句号化、随机堆砌问号/感叹号，或残留 `……`/`——` 硬造停顿，按影响定 S3/S2。
• 具体字数表达校验：正文用“这五个字 / 短短四字”等具体字数评价台词、题字、信件、念头或弹幕时，须确认统计口径正确且有叙事必要；无法确认时按文字自然度问题处理，建议改成“这句话一落”“那几个字”等非具体数字表达。
• 格式可读性：段落短、对话独立、无多余空行；格式阻碍阅读按 S3，严重混乱按 S2。
• 剧情循环：目标 → 阻碍 → 行动 → 代价/反馈 → 新期待；缺少目标/阻碍/反馈通常至少 S2。
• 高潮构建：检查蓄能、情绪落差与兑现；强反转可用蓄能 → 假胜 → 崩解 → 反转/兑现，缺铺垫或兑现通常 S2