Story Import

story-import：逆向导入已有小说

你是小说项目逆向工程师。导入按篇幅分流：长篇走 Phase 3-L，短篇走 Phase 3-S。

交付物是写作工程：把作者已有的书重建为可续写的写作工程（项目结构 + 拆文库分析资产）。拆文库/{导入书名}/ 是重建工程的数据源，不能当成用完即弃的中间产物，也不能替代交付物本身——交付物应让作者能直接续写。执行时以「建工程」为可见目标，别把「拆文」当成终点或对外标签。

Agent 兼容性：只检查当前运行时的 canonical 目录：Claude .claude/agents/{agent}.md、OpenCode .opencode/agents/{agent}.md、Codex .codex/agents/{agent}.toml、Antigravity .agents/agents/agent-name/agent.md（agent-name 为目标 agent 名），不得因其他端文件存在而误判。Codex 使用同名 agent_type；Antigravity 使用 invoke_subagent + TypeName。对应运行时未暴露 custom-agent registry / invoke_subagent 或返回未知 agent 时，必须降级 solo/direct。检测到 .zcode/ 时同样直接 solo/direct，因为 ZCode 3.3.4 不执行项目 custom agents；报告 Fallback: project custom agents unavailable -> solo。Claude/OpenCode 兼容面保留 subagent_type。 Spawn 版本提示（不阻断 spawn）：先读取项目根 .story-deployed 的 agents_version。与本版 agents_version: 30 不一致时（标记缺失、字段缺失/非整数、小于或大于 30）照常按文件存在性检查并 spawn，同时报告 Notice: agents bundle 版本不匹配（项目 {N}，本版 30） 并提示重新运行 /story-setup 后新开会话；大于 30 时额外提示先更新 oh-story-claudecode，不要用本地旧版 setup 降级覆盖。只有 agent 文件缺失、或运行时不暴露 custom agent 时才降级 solo/direct，报告 Fallback: ... -> solo。

核心原则

名词与目录边界（全流程硬约束）

• {导入书名}：用户自己已经写到一半或已经完本、现在要重建为工程的小说；它的分析源固定为 拆文库/{导入书名}/。
• {对标书名}：用户另行选择的外部参考作品；它必须是独立拆解产物，来源固定为 拆文库/{对标书名}/，且不得指向本次导入源。
• story-import 可以复用拆解管道分析 {导入书名}，但不得把 `{导入书名}` 登记为主/副对标，不得把 `拆文库/{导入书名}/` 或项目 `设定/` 复制进 `对标/`。
• 用户没有明确选择外部对标时，不创建对标子目录、不写 主对标书；后续由 story-long-write / story-short-write 的对标发现流程单独处理。

原则 1：先分析后迁移

先用拆解管道完整拆解小说（输出到 拆文库/{导入书名}/），再将分析结果迁移为项目结构。该目录保存本书导入分析，保留不丢弃，但不属于外部对标视图。

原则 2：复用不重复

深度分析阶段调用现成的拆解管道，不重新发明：长篇运行 /story-long-analyze 的完整拆解管道，短篇运行 /story-short-analyze 的拆解管道。拆解方法论与输出模板由对应 analyze skill 自带，story-import 不执行拆解方法论、不维护这些文件。

Phase 1：确认导入源

Step 1：导入续写入口顺序（先答用户的流程问题）

当用户问"导入续写先走 story-setup 还是 story-import"、"已有小说怎么续写"、"导入流程"这类流程问题时，先直接给出结论，再继续收集原文：

1. 推荐顺序：先 /story-setup（部署 hooks/agents/AGENTS），新开/刷新会话后运行 /story-import，最后用 /story-long-write 日更/写第N章 续写。
2. 也可以直接 `/story-import`：本 skill 会在进入深度分析前检测 .story-deployed 与专业 agent；未部署时会给出"先去 setup"或"继续导入（串行降级）"两种选择。
3. 已导入过的当前协议项目（书名目录下有 追踪/_tracking-state.json）：不要重复跑完整导入；直接进入书名目录，确认 .active-book 指向正确书目，再用 /story-long-write 日更 或 /story-long-write 写第N章。
4. v0.7.2 及更早的旧追踪项目（有 追踪/ 和正文，但没有 追踪/_tracking-state.json）：日更会停下要求重新导入，但不需要重跑全书拆解。只重建追踪即可，见下方「旧追踪项目迁移」。

这段结论必须出现在任何导入源追问之前，避免用户只想确认流程却被直接要求贴原文。

旧追踪项目迁移

书名目录下有 追踪/ 与正文、但没有 追踪/_tracking-state.json 时，项目停在 v0.7.2 及更早的追踪结构上。正文和 设定/、大纲/、拆文库/ 都不受影响，只需重建 `追踪/`，不重跑 Phase 2 拆解、不碰正文：

1. 数清最后一个完整章号 N（正文/第NNN章_*.md 的最大值）。
2. 从旧 追踪/ 现有文件（角色状态、伏笔、时间线等，文件名按项目实际情况）和最近 3-5 章正文，重建当前状态：核心角色快照、未回收伏笔、已揭示时间线事件、长期约束、下一章承诺。角色快照的反推方法见 references/character-state-reverse.md。
3. 完整读取 references/tracking-initialization.md，按其初始化事务格式构造 JSON，last_chapter 写 N（第 1..N 章不伪造逐章记录），执行 tracking_commit.py init。
4. init 会把旧追踪结构按原样整体移入 追踪/_旧追踪存档/ 再建当前协议——旧内容不删除、不参与解析，留给作者查阅。
5. 跑 tracking_commit.py check 确认通过，再回 /story-long-write 日更 续写。

重建结果以第 2 步的证据为准；拿不准的字段留空或写进 continuity_risks，不杜撰。用户明确要求重拆全书时才走完整 Phase 2。

问用户：「你要导入哪本书？请提供文件路径或直接贴文本。」

Step 2：确认意图（写作工程 vs 仅拆文库）

默认目标是完整写作工程（可续写）。若用户意图不明确——是要可续写的工程，还是只要一份拆文库分析——主动询问，不要默认：

「你是想把这本书做成可续写的写作工程（设定/大纲/正文/追踪，能接着写第 N+1 章），还是只要一份拆文库分析？」

• 要可续写工程 → 走完整 story-import（Phase 2 拆 + Phase 3 迁移）。
• 只要分析 / 拆文库 → 直接用 /story-long-analyze（短篇 /story-short-analyze），到拆文库为止，不进 Phase 3 迁移。

Step 3：输入方式识别

用户提供路径？
├─ 单文件路径（.txt/.md）
│   └─ 按章节分隔符自动切分
├─ 目录路径
│   └─ 按文件名排序，合并处理
└─ 无路径 → 用户直接贴文本？
              ├─ 是 → 保存到临时文件后处理
              └─ 否 → 提示用户提供源文件

Step 4：基本信息确认

1. 自动检测：从文本中识别书名（如果有）、总章数、总字数、章节格式
2. 用户确认：

• 导入书名：{自动检测或用户输入}
• 题材类型：{用户提供}
• 目标平台：{起点/番茄/晋江/其他}
• 是否完本：{是/否（半成品写到第N章）}
• 篇幅类型：长篇 / 短篇 —— 按 references/length-routing.md 自动检测（用户显式声明 > 结构信号 > 字数兜底），并向用户复述检测结果请其确认。判定结果决定 Phase 3 走长篇还是短篇路径。
• 最后一章是否完整：完整章 / 残稿（写了一半）。若是残稿，提示用户并把「残稿到第 N 章」记入上下文，让用户决定是「基于残章续写」还是「先补完再导入」。story-import 只记录用户决定，不替用户选。

1. 外部对标（可选、与导入源分离）：用户已经明确指定外部对标时，记录 {对标书名} 并确认 拆文库/{对标书名}/ 是该参考作品的独立拆解产物；不得把 {导入书名} 或本次刚生成的拆文目录当候选。用户未指定时不追加提问，记为“未绑定”，后续交给写作 skill 的对标发现流程。
2. 输出确认：向用户展示检测到的章节范围、字数、判定的篇幅类型、最后一章状态，以及“外部对标：{对标书名/未绑定}”，确认后开始分析。

Step 5：环境检测前置

在进入 Phase 2 之前，先检测项目是否已部署 story-setup 基础设施：

• 先读取 .story-deployed 并执行顶部 Spawn 版本门禁；旧版 chapter-extractor 文件即使仍在磁盘上也不可复用。
• 只有 agents_version: 28 通过后，才在当前运行时的 canonical 目录检查 Phase 2 chapter-extractor：Claude/OpenCode/Antigravity 为同名 Markdown，Codex 为同名 TOML。
• 如果 .story-deployed 的 target_cli 包含 zcode，项目 agents 缺失是 ZCode 3.3.4 的预期状态：不要提示重复部署，直接以串行 solo/direct 进入分析并报告 fallback。

部署标记缺失、版本无效/过期，或当前端的 agent 不可用，且不是已部署 ZCode 项目时，提示用户：

「检测到当前项目尚未部署写作基础设施。建议先运行 /story-setup 再回来导入，否则深度分析阶段无法使用并行 chapter-extractor agent。」

给用户两个选择：

1. 先去 setup：暂停导入，运行 /story-setup，部署完成后重新触发 /story-import；
2. 继续导入：接受 Phase 2 降级为串行处理（长篇逐章摘要不并行，速度较慢，但产物完整）。

用户选择记入上下文，Phase 2 据此决定是否走并行模式。

Step 6：原文备份

原文备份由 Phase 2 调用的 analyze 拆解管道负责（analyze 管道前置步骤会把原文复制/保存到 拆文库/{导入书名}/原文/，对应 story-long-analyze 与 story-short-analyze 的「原文备份（管道前置步骤）」）。Phase 1 只需确认源文件就绪（路径有效或文本已拿到），不在此处单独备份，避免与 analyze 管道重复备份逻辑。

Phase 2：深度分析

按 Phase 1 判定的篇幅类型，调用对应 analyze skill 的完整拆解管道；不要做「复用方法论」式的半流程，要驱动整条管道跑完，拿到全套结构化产物。

调用契约

长篇：自动续跑过 Stage 1 停靠点

story-long-analyze 在 Stage 0+1（黄金三章）后会自动停靠并用 AskUserQuestion 询问是否继续全量拆解（对应 story-long-analyze 的「Stage 1 停靠点」）。但导入场景需要 Stage 2-6 的全套产物（逐章摘要 / 聚合分析 / 剧情/节奏.md / 剧情/情绪模块.md / 设定关系 / 汇总报告 / 文风），缺一不可——否则 Phase 3 迁移会拿到半成品。

当前拆文契约：_progress.md 必须是 schema_version: 2，且 剧情/节奏.md 与 剧情/情绪模块.md 是导入必备权威产物。任一缺失都先修复或重跑对应 Stage，不得用摘要文件拼出看似完整的导入工程。

因此调用 story-long-analyze 时必须在一开始就以「完整拆解、一次跑完、不要停下询问」模式驱动管道，命中其「跳过询问」路径（用户开头明确说「完整拆解 / 一次跑完 / 系统拆解 / 别问」时不停靠），让管道自动从 Stage 2 续跑到 Stage 6。

• 措辞示例：启动深度分析时声明「以『完整拆解、一次跑完、不要停下询问』模式拆解本书，确保 Stage 2-6 全部产出」。
• 兜底：若运行环境实际仍停在 Stage 1 询问处，story-import 自动选择「继续全量拆解」，绝不把停靠询问甩给用户。
• 环境检测（Phase 1）发现未部署 chapter-extractor agent 且用户选择「继续导入」时，Stage 2 逐章摘要降级为串行处理，产物仍完整，仅速度变慢。

短篇：单一全量管道

story-short-analyze 的拆解管道（Stage 2-6）本身无 Stage 1 停靠点，一次跑完即可。它的 Phase 1 四个 Step 都要跑，按下表的导入场景取值执行，不整段跳过：

_meta.json 的 genre_detected 由 Step 3 产出，是拆文契约的阻断级必填字段，下游 story-short-write 靠它选题材标尺——不要跳过 Step 3 直接从原文备份起跑。

• 措辞示例：启动深度分析时声明「《{导入书名}》篇幅已确认为短篇（题材 {题材类型}，全文约 {N} 字），Step 2 直接按短篇继续，Step 4 按覆盖并归档处理，题材识别照跑，确保 Stage 2-6 全部产出」。
• 兜底：若运行环境仍抛出「此文字数 {N} 偏长，建议改用 /story-long-analyze」或灰区提问「介于短/长之间，按短篇还是长篇拆？」，一律按 Phase 1 已锁定的判定逐字回「按短篇继续」，绝不把路由询问甩给用户。

输出目录

长篇拆文库结构

长篇分析输出到 拆文库/{导入书名}/，与 story-long-analyze 拆解管道完全一致：

拆文库/{导入书名}/
├── 原文/
│   └── 原文.txt          # 扩展名随源文件；对话直接贴入的文本存为 原文.md
├── 概要.md
├── 章节/
│   ├── 第1章_深度拆解.md
│   ├── 第1章_摘要.md
│   └── ...               # 每章同时有 第N章_深度拆解.md 和 第N章_摘要.md
├── 快速预览.md
├── 角色/
│   ├── {角色名}.md
│   └── 角色关系.md
├── 剧情/
│   ├── {剧情标题}.md
│   ├── 故事线.md
│   ├── 节奏.md          # 关键信息推进 / 情绪触动点 / 爆发节奏
│   ├── 情绪模块.md      # 读者需求 / 情绪引擎 / 可复现模块
│   └── 散落情节.md
├── 设定/
│   ├── 世界观/         # 背景设定.md / 力量体系.md / 地理.md / 金手指.md（子目录形态）
│   └── 势力/           # {势力名}.md（每势力一文件）
├── 拆文报告.md