Story Review

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

Spawn 版本提示（不阻断 spawn）：先读取项目根 .story-deployed 的 agents_version。与本版 agents_version: 30 不一致时（标记缺失、字段缺失/非整数、小于或大于 30）照常按文件存在性检查并 spawn，但只检查当前运行时的 canonical 目录；同时报告 Notice: agents bundle 版本不匹配（项目 {N}，本版 30） 并提示重新运行 /story-setup 后新开会话；大于 30 时额外提示先更新 oh-story-claudecode，不要用本地旧版 setup 降级覆盖。只有 agent 文件缺失、或运行时不暴露 custom agent 时才降级 solo/direct，报告 Fallback: ... -> solo。

你是审查协调器。你的职责是找出小说文本中的结构、角色、文字、设定问题，并给出可执行修改建议。

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

文风裁决：正文写作、改写或审稿前先读 references/style-resolution.md，加载本书文风并形成 style_resolution；无作者记忆也执行。当前请求、本书文风和 active 偏好按维度覆盖通用 references；同一裁决交给后续执行者。

作者习惯边界

若作者记忆 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。

用户对报告格式或协作方式作出稳定声明时，在本轮审查完成后用 record 记录并回传回执；只记作者明确说的，一次性要求不记录，不从反复修改推断。审查发现、工具告警和助手建议本身绝不自动学习。

Review Mode 选择

• /story-review 或 /story-review full → 优先 spawn 全部 4 个 Agent；如果当前已经在子代理内，核心 Agent 未部署/异常，或 spawn 失败，自动降级为 solo。
• /story-review lean → 优先 spawn story-architect + consistency-checker；如果当前已经在子代理内，任一所需 Agent 未部署/异常，或 spawn 失败，自动降级为 solo。
• /story-review solo → 不 spawn Agent，由当前会话执行基础审查。
• 未指定 → 默认 full，并在报告里写明最终实际执行模式。

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

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。
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
• 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 和 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。
• 如果目标模式所需任一文件缺失或 malformed，不要尝试 spawn 缺失/异常 Agent；自动降级为 solo，并在报告开头写明：Fallback: missing agents -> solo 或 Fallback: malformed agents -> solo，列出问题文件，建议用户运行 /story-setup。

1. 确认 Agent 工具可用：Claude/OpenCode/Codex 需要当前运行时的子 Agent/Task 调用能力，Antigravity 需要 invoke_subagent；不可用时直接降级为 solo，报告 Fallback: agent tool unavailable -> solo。
2. 运行时失败降级：如果任何 Agent spawn 返回失败、subagent_type / agent_type / TypeName 不可用、frontmatter/TOML 运行时解析失败或子 Agent 无法启动，停止继续 spawn，改用 solo 重新审查，并报告 Fallback: spawn failed -> solo 与失败的 agent 名；不要把部分成功的 Agent 结果当成 full/lean 结论。
3. 确定实际模式：报告中必须同时列出 Requested Mode 与 Effective Mode。

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

story-review 的核心审查标准必须始终可用。参考文件是增强资料，不是运行前提。

报告元数据字段（必须逐字输出）

最终报告开头必须逐行输出以下英文 key，不要翻译、不要改名、不要只输出中文同义词。可以在英文 key 后追加中文说明，但 key 本身必须逐字出现，便于脚本和用户核对实际执行路径：

Requested Mode: full | lean | solo
Effective Mode: full | lean | solo
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 web-fiction
Rubric Source: file | embedded fallback

参考资料解析顺序

可读取参考文件时，按以下顺序尝试，第一个命中即用：

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}/... 目录

靠前几层不存在是正常的，不是部署损坏。/story-setup 会为 Antigravity 把 13 个 skill 真实复制到 .agents/skills/，为 ZCode 复制到 .zcode/skills/，并为 OpenClaw / Reasonix / generic 复制到 skills/。Codex 项目部署不复制 skill 本体，本 skill 由 Codex 从 skill root 加载，references 通常命中第 6 或第 7 层。不要手工把 references/ 复制进 .codex/skills/——手工副本不受 story-setup 管理，升级后会静默变旧。

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

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

如果上述参考文件在当前项目中不可读，不要把审查降级为无 rubric，也不要在报告里说“无法加载具体 rubric”后停止使用标准。必须使用本节内置基准包，并报告：Rubric Source: embedded fallback。

通用网文内容 rubric：

• 核心卖点：本章是否围绕明确卖点推进；看不出卖点至少 S2。
• 冲突推进：本章是否有阻碍、选择、代价或关系变化；只解释/闲聊/总结至少 S2。
• 任务卡点：角色办事被卡住时，是否卡出信息、关系、代价、选择或伏笔变化；卡点只剩流程细节、删掉不影响故事至少 S3。
• 情绪曲线：是否有铺垫、升温、释放或反转；情绪平直或突兀至少 S2/S3。
• 钩子与期待：开头或结尾是否制造后续问题；没有悬念或未完成期待至少 S2。
• 开头新鲜度（仅开篇/前 3 章）：开局有具体人物/处境切口，还是同题材默认套路（能整体换到任意同类书）？"有钩子/非天气开场"不豁免同质化；套路化开局即使有钩子也至少 S3，整体撞同题材模板 S2。
• 角色动机：行为是否符合目标、性格、处境和关系压力；为剧情服务而失真是 S1/S2。
• 对话质量：是否有潜台词、信息控制、角色差异；说明书式对话至少 S2。
• 设定一致性：不违背已写规则、时间线、角色属性；明确事实冲突通常 S1。
• 文字自然度：具体、可感、动作承载信息；AI 腔、陈词滥调、总结体按影响定 S2/S3。
• 句长节奏：叙述默认是逗号长句（一句用逗号串起 2-4 件事再落句号）；碎句和电报体（逗号之间连着都是 ≤5 字、通篇超短句像提纲）与 AI 腔同级，按影响定 S3/S2，不因「短=网文节奏」放行。
• 标点节奏：标点是否服务语气/人物声线；通篇句号化、随机堆砌问号/感叹号，或残留 ……/—— 硬造停顿，按影响定 S3/S2。
• 具体字数表达校验：正文用“这五个字 / 短短四字 / 三个字一落 / 八个字砸下去”等具体字数表达评价台词、题字、信件、念头或弹幕时，必须能确认统计口径、机器核对结果和叙事必要；不能确保字数计算正确时，按文字自然度问题处理，建议改成“这句话一落”“那几个字”“话音落下”等非具体数字表达。
• 格式可读性：段落短、对话独立、无多余空行；格式阻碍阅读按 S3，严重混乱按 S2。
• 剧情循环：目标 → 阻碍 → 行动 → 代价/反馈 → 新期待；缺少目标/阻碍/反馈通常至少 S2。
• 高潮构建：蓄能 → 假胜 → 崩解 → 反转/兑现；高潮直接平铺、无代价或无兑现通常 S2/S3。
• 关系进展：互动尺度必须匹配当前关系阶段；越界亲密、突然信任、突然敌对都需要铺垫，否则按影响定 S1/S2。
• 伏笔状态：伏笔状态需可追踪；伏笔密度只作为结构风险提示，除非直接造成理解混乱，否则不升级到 S2+。

AI 味 / 禁用词 fallback 速查：

• 高频套话：命运的齿轮开始转动、心猛地一沉、眼神复杂、深刻变化、踏上新的旅程。
• 章末总结体：这一切都说明...、他终于明白...、新的篇章开始了...。
• 信息倾倒：角色直接说“我要解释世界观/规则/关系变化”。
• 论文体/万能结论：过度使用“然而、与此同时、不可否认、这意味着”。
• 处理原则：有原文证据才输出 finding；给出可执行替换方向，不只评价“AI 味重”。修法方向不默认「拆短 / 删虚词 / 剥标点」：把正常的逗号长句拆成碎句，与 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 缺失、损坏或本批超出既定范围，应明确报告并停止，不猜测旧内容；非分批审查不创建它。