story-import

name story-import version 1.0.0 description 逆向导入已有小说。将已写好的小说（半成品或完本）反向解析为标准项目目录结构，兼容 story-long-write / story-short-write 后续写作流程；内部复用 story-long-analyze / story-short-analyze 的拆解管道，按篇幅自动分流。触发方式：/story-import、「导入小说」「反向解析」「导入」「把我的书导进来」。 metadata {"openclaw":{"source":"https://github.com/zenstory-ai/oh-story-claudecode"}} 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"、"已有小说怎么续写"、"导入流程"这类流程问题时，先直接给出结论，再继续收集原文： 推荐顺序 ：先 /story-setup （部署 hooks/agents/AGENTS），新开/刷新会话后运行 /story-import ，最后用 /story-long-write 日更/写第N章 续写。 也可以直接 /story-import ：本 skill 会在进入深度分析前检测 .story-deployed 与专业 agent；未部署时会给出"先去 setup"或"继续导入（串行降级）"两种选择。 已导入过的当前协议项目 （书名目录下有 追踪/_tracking-state.json ）：不要重复跑完整导入；直接进入书名目录，确认 .active-book 指向正确书目，再用 /story-long-write 日更 或 /story-long-write 写第N章 。 v0.7.2 及更早的旧追踪项目 （有 追踪/ 和正文，但没有 追踪/_tracking-state.json ）：日更会停下要求重新导入，但 不需要重跑全书拆解 。只重建追踪即可，见下方「旧追踪项目迁移」。 这段结论必须出现在任何导入源追问之前，避免用户只想确认流程却被直接要求贴原文。 旧追踪项目迁移 书名目录下有 追踪/ 与正文、但没有 追踪/_tracking-state.json 时，项目停在 v0.7.2 及更早的追踪结构上。正文和 设定/ 、 大纲/ 、 拆文库/ 都不受影响， 只需重建 追踪/ ，不重跑 Phase 2 拆解、不碰正文： 数清最后一个完整章号 N （ 正文/第NNN章_*.md 的最大值）。 从旧 追踪/ 现有文件（角色状态、伏笔、时间线等，文件名按项目实际情况）和最近 3-5 章正文，重建当前状态：核心角色快照、未回收伏笔、已揭示时间线事件、长期约束、下一章承诺。角色快照的反推方法见 references/character-state-reverse.md 。 完整读取 references/tracking-initialization.md ，按其初始化事务格式构造 JSON， last_chapter 写 N （第 1..N 章不伪造逐章记录），执行 tracking_commit.py init 。 init 会把旧追踪结构按原样整体移入 追踪/_旧追踪存档/ 再建当前协议——旧内容不删除、不参与解析，留给作者查阅。 跑 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：基本信息确认 自动检测 ：从文本中识别书名（如果有）、总章数、总字数、章节格式 用户确认 ： 导入书名：{自动检测或用户输入} 题材类型：{用户提供} 目标平台：{起点/番茄/晋江/其他} 是否完本：{是/否（半成品写到第N章）} 篇幅类型 ：长篇 / 短篇 —— 按 references/length-routing.md 自动检测（用户显式声明 > 结构信号 > 字数兜底），并向用户复述检测结果请其确认。判定结果决定 Phase 3 走长篇还是短篇路径。 最后一章是否完整 ：完整章 / 残稿（写了一半）。若是残稿，提示用户并把「残稿到第 N 章」记入上下文，让用户决定是「基于残章续写」还是「先补完再导入」。story-import 只记录用户决定，不替用户选。 外部对标（可选、与导入源分离） ：用户已经明确指定外部对标时，记录 {对标书名} 并确认 拆文库/{对标书名}/ 是该参考作品的独立拆解产物；不得把 {导入书名} 或本次刚生成的拆文目录当候选。用户未指定时不追加提问，记为“未绑定”，后续交给写作 skill 的对标发现流程。 输出确认 ：向用户展示检测到的章节范围、字数、判定的篇幅类型、最后一章状态，以及“外部对标：{对标书名/未绑定}”，确认后开始分析。 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。」 给用户两个选择： 先去 setup ：暂停导入，运行 /story-setup ，部署完成后重新触发 /story-import ； 继续导入 ：接受 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 的 完整拆解管道 ；不要做「复用方法论」式的半流程，要驱动整条管道跑完，拿到全套结构化产物。 篇幅 调用的拆解管道 产物目录 长篇 story-long-analyze 的完整管道（Stage 0-6） 拆文库/{导入书名}/ 短篇 story-short-analyze 的拆解管道（Stage 2-6） 拆文库/{导入书名}/ 调用契约 长篇：自动续跑过 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 都要跑，按下表的导入场景取值执行，不整段跳过： Phase 1 步骤 导入场景下的处理 Step 1：拿到原文 用 story-import Phase 1 已确认的源文件，不重新问 Step 2：字数检查（长短篇路由） 篇幅已在 story-import Phase 1 判定并经用户确认，直接答「按短篇继续」，不重新路由 Step 3：题材识别 照常跑 ，题材标尺必须加载；story-import Phase 1 Step 4 已确认的题材类型直接代入，不重复提问 Step 4：续跑检查（ 拆文库/{导入书名}/_meta.json 已存在时三选一） 先看旧产出是否可直接复用： stages_completed 已含 6 且 拆文报告.md / 情节节点.md / 写作手法.md / 原文/ 均非空、来源与本次导入源一致 → 直接进 Phase 3，不重跑也不归档。否则本轮首次进入 Phase 2 → 按 (a) 覆盖：先把旧产出归档到 拆文库/{导入书名}/_archive_{时间戳}/ ，再从 Stage 2 重跑；同一轮导入内重试同一本书 → 按 (b) 续跑。不把三选一甩给用户，也不跳过归档 _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 ├── 文风.md # Stage 6 文风：写作技法视图 + 原文范例锚点 └── _progress.md 短篇拆文库结构 短篇分析输出到 拆文库/{导入书名}/ ，与 story-short-analyze 拆解管道一致： 拆文库/{导入书名}/ ├── 原文/ │ └── 原文.txt # 扩展名随源文件；对话直接贴入的文本存为 原文.md ├── 拆文报告.md ├── 情节节点.md ├── 写作手法.md └── _meta.json # 管道元数据 + 结构计数（下游 story-short-write 必读） 长篇完整管道（Stage 0-6） 管道详细说明见 story-long-analyze（运行 /story-long-analyze ），此处仅列概要。 阶段 名称 输入 输出 完成标志 0 概要提取 原始文本 概要.md + 章节索引 章节结构识别完成 1 黄金三章 前 3 章原文 第1章_深度拆解.md / 第2章_深度拆解.md / 第3章_深度拆解.md → 停靠产出快速预览.md （导入场景自动续跑，不停下询问） 3 章拆解完成 2 逐章摘要 分块章节文本 章节摘要.md（含情节点+角色+ 关键信息与扩写技法 ）。每章10-40情节点（密度150-200字/个，按字数动态调节）。角色过滤（龙套不提取、别名归类）。 并行 chapter-extractor agent 模式 （未部署 agent 时降级串行）。 计数验证：摘要数 == 章节数 。 所有章节处理完成 3 聚合分析 全部章节摘要 剧情/*.md + 剧情/README.md + 剧情/故事线.md + 剧情/节奏.md + 剧情/情绪模块.md 。 故事框架识别 （前置）。 两步法剧情聚合 （先从摘要识别剧情大纲，再按大纲分配情节点）。 关键信息推进索引 、 情绪触动点与爆发节奏 、 读者需求 / 情绪引擎 / 可复现模块 。 角色合并 （跨章节去重+别名归一）。 角色分级 （主角/反派/核心配角/功能角色）。 散落情节兜底 （6步，含覆盖率验证）。 质量检查 （置信度>=0.85/覆盖率85%-95%/重叠率<=35%）。 质量检查通过 4 设定+关系 阶段 3 合并后角色数据+情节点 设定/ .md + 角色/ .md。 两阶段角色模型 。 别名解析 （置信度≥0.85自动合并）。 设定和关系提取完成 5 汇总报告 全部输出 拆文报告.md（含「读者需求 / 情绪引擎」「关键信息与扩写技法总览」「节奏与情绪触动点」「可复现模块」，并指向 剧情/节奏.md / 剧情/情绪模块.md ） 报告生成完成 6 文风 拆文报告.md + 章节/第1-3章_深度拆解.md + 章节/*_摘要.md + 原文/原文.txt 文风.md（本书历史写法分析） 文风落盘 拆文库/{导入书名}/文风.md ，保留为导入分析，不复制到本书 对标/ 短篇拆文管道 管道详细说明见 story-short-analyze（运行 /story-short-analyze ），此处仅列概要。 短篇为单一全量管道（Stage 2-6 严格串行），产物落盘 拆文库/{导入书名}/ ：Stage 2 结构+情节节点 → Stage 3 情感线+爆点 → Stage 4 反转+写作手法 → Stage 5 人物+开头结尾 → Stage 6 综合评估，最终汇总为 拆文报告.md 、 情节节点.md 、 写作手法.md ，另有 _meta.json 记管道元数据与结构计数。 长篇分块沿用 story-long-analyze：Stage 2 用 chapter-extractor agent 并行，其余阶段按该 skill「分块策略」的章数阈值执行，story-import 不另定一套。 恢复机制 中断时通过进度文件追踪进度 新会话读取进度文件定位断点 从断点所在块的起始章节恢复 长篇进度文件格式沿用 story-long-analyze 拆解管道的进度段落约定，包含当前阶段、最后处理章节、已完成阶段列表、更新时间 质量检查 长篇阶段 3-4 完成前执行质量检查（置信度 >= 0.85，覆盖率 85%-95%，重叠率 <= 35%），由 story-long-analyze 拆解管道自带的质量检查负责。短篇质量检查见 story-short-analyze 各阶段的完成标志。 Phase 3：结构迁移 将 拆文库/{导入书名}/ 的分析结果迁移为可被写作 skill 消费的项目结构。 分流路由 按 Phase 1 判定的篇幅类型分流，两条路径产出的工程结构完全不同： 篇幅 迁移路径 映射规则 续写接手 长篇 3-L：长篇结构迁移 references/structure-mapping-long.md story-long-write 日更循环 短篇 3-S：短篇结构迁移 references/structure-mapping-short.md story-short-write Phase 3 逐场景写作 Phase 3-L：长篇结构迁移 将 拆文库/{导入书名}/ 的分析结果迁移为 {导入书名}/ 长篇项目结构。迁移规则详见 references/structure-mapping-long.md 。 迁移步骤 Step 1：创建项目骨架 {导入书名}/ ├── 设定/ │ ├── 世界观/ │ ├── 角色/ │ └── 势力/ ├── 大纲/ ├── 正文/ ├── 追踪/ │ └── 逐章记录/ ├── 对标/ # 可选；仅在显式绑定外部对标时创建子目录 └── 参考资料/ Step 2：正文标准化 将原文迁移到 正文/ ，统一命名格式： 第XXX章_章名.md 。 识别章节分隔符（第X章、Chapter X 等） 提取章节标题 补零对齐编号（第1章 → 第001章） 保留原文内容不变 Step 3：角色文件迁移 将 拆文库/{导入书名}/角色/{角色名}.md 迁移到 设定/角色/{角色名}.md 。 迁移时按 references/structure-mapping-long.md 的「角色文件迁移模板」补齐 story-long-write 角色模板字段。 角色分级（沿用 story-long-analyze 标准）： 等级 标准 迁移策略 主角 出现章节 ≥50% + 推动主线 + 完整成长轨迹 完整迁移 反派 与主角对立 + 推动核心冲突 + 明确动机 完整迁移 核心配角 出现章节 ≥20% 或推动重要支线 完整迁移 功能角色 出现章节 <20% + 作用有限 简化迁移 Step 4：关系文件迁移 将 拆文库/{导入书名}/角色/角色关系.md 转换为 设定/关系.md ，按 structure-mapping-long.md 「关系文件转换规则」的目标格式模板输出。 Step 5：同步世界观设定 当前拆文契约已按主题输出 拆文库/{导入书名}/设定/世界观/*.md 与 设定/势力/*.md 。导入时原样同步到项目； 世界观/ 必须包含 背景设定.md 。 力量体系.md 小于 200 字并已并入 背景设定.md 时可省略；否则缺失当前必需产物时停止并提示重跑 story-long-analyze Stage 4。不再现场拆分扁平文件。