逆向导入已有小说。将已写好的小说（半成品或完本）反向解析为标准项目目录结构，兼容 story-long-write / story-short-write 后续写作流程；内部复用 story-long-analyze / story-short-analyze 的拆解管道，按篇幅自动分流。触发方式：/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](references/character state reverse.md)。 3. 完整读取 [references/tracking initialization.md](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：输入方式识别 Step 4：基本信息确认 1. 自动检测：从文本中识别书名（如果有）、总章数、总字数、章节格式 2. 用户确认：导入书名：{自动检测或用户输入} 题材类型：{用户提供} 目标平台：{起点/番茄/晋江/其他} 是否完本：{是/否（半成品写到第N章）} 篇幅类型：长篇 / 短篇 —— 按 [references/length routing.md](references/length routing.md) 自动检测（用户显式声明结构信号字数兜底），并向用户复述检测结果请其确认。判定结果决定 Phase 3 走长篇还是短篇路径。最后一章是否完整：完整章 / 残稿（写了一半）。若是残稿，提示用户并把「残稿到第 N 章」记入上下文，让用户决定是「基于残章续写」还是「先补完再导入」。story import 只记录用户决定，不替用户选。 3. 外部对标（可选、与导入源分离）：用户已经明确指定外部对标时，记录 {对标书名} 并确认拆文库/{对标书名}/ 是该参考作品的独立拆解产物；不得把 {导入书名} 或本次刚生成的拆文目录当候选。用户未指定时不追加提问，记为“未绑定”，后续交给写作 skill 的对标发现流程。 4. 输出确认：向用户展示检测到的章节范围、字数、判定的篇幅类型、最后一章状态，以及“外部对标：{对标书名/未绑定}”，确认后开始分析。 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 的完整拆解管道；不要做「复用方法论」式的半流程，要驱动整条管道跑完，拿到全套结构化产物。篇幅调用的拆解管道产物目录长篇 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 拆解管道完全一致：短篇拆文库结构短篇分析输出到拆文库/{导入书名}/ ，与 story short analyze 拆解管道一致：长篇完整管道（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](references/structure mapping long.md) story long write 日更循环短篇 3 S：短篇结构迁移 [references/structure mapping short.md](references/structure mapping short.md) story short write Phase 3 逐场景写作 Phase 3 L：长篇结构迁移将拆文库/{导入书名}/ 的分析结果迁移为 {导入书名}/ 长篇项目结构。迁移规则详见 [references/structure mapping long.md](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](references/structure mapping long.md)「关系文件转换规则」的目标格式模板输出。 Step 5：同步世界观设定当前拆文契约已按主题输出拆文库/{导入书名}/设定/世界观/ .md 与设定/势力/ .md 。导入时原样同步到项目；世界观/ 必须包含背景设定.md 。力量体系.md 小于 200 字并已并入背景设定.md 时可省略；否则缺失当前必需产物时停止并提示重跑 story long analyze Stage 4。不再现场拆分扁平文件。 Step 6：大纲生成大纲.md （卷级结构）：从剧情/故事线.md 、剧情/ .md 和快速预览.md 反推。卷划分采用用户确认制，规则见 [structure mapping long.md](references/structure mapping long.md)「大纲反推规则」：原文有明确卷界（存在「第一卷」「卷一」等卷级标题）→ 按原文卷界直接划分，无需询问。原文无明确卷界 → 不机械按「每卷 20 40 章」硬切。根据故事线/场景切换/大型时间跳跃检测候选卷边界，向用户展示候选划分方案，等待用户确认后才写定卷纲；用户确认前大纲/大纲.md 只记录候选方案。卷纲：卷划分确认后，从剧情文件聚合生成大纲/卷纲第X卷.md ，按 [structure mapping long.md](references/structure mapping long.md)「卷纲反推」模板格式。细纲：从章节摘要反推生成大纲/细纲第XXX章.md ：每章先通过 story long write 的 Wordcount Core 运行 wordcount measure ，将 JSON 的 actual 作为已写章节的历史长度快照。这里记录的是原文在 visible chars v1 下的实际长度，不是让模型重新决定创作目标。依次探测 python3 、 python 、 py 3 ；找不到 Python 3 或 CLI 时返回 TOOL UNAVAILABLE 并停止导入，不得用模型估算或静默跳过。钩子、人物关系变化、辅线/感情线、行动成本/收益归属等无法由原文摘要稳定判断的字段统一标 [待补充] ；story import 只反推有证据的蓝图，不为补齐字段编造关系或副线。 Step 7：追踪文件生成导入项目必须通过本 skill 自带的 scripts/tracking commit.py init 一次性生成追踪状态，禁止模型分别写最终文件。完整字段与命令见 [references/tracking transaction.md](references/tracking transaction.md)。语义准备顺序如下： 1. 导入截止章：把最后完整章 N 写入初始化事务的 last chapter 。工具在 meta 记录 imported through chapter=N ；导入旧章没有日更事务，不得为第 1..N 章伪造逐章增量，也不额外生成一份重复当前状态的叙事基线。 2. 核心角色当前快照：从拆书产物反推主角、反派、核心配角的截至 N 章状态，按角色写入初始化 JSON 的 character snapshots 。输出由工具生成到追踪/角色状态/{角色名}.md ；算法见 [references/character state reverse.md](references/character state reverse.md)。 3. 伏笔当前行：从有正文证据的铺垫/回收事件生成 foreshadow 。每个 ID 只保留当前状态一行；尚未实际埋设的未来设计留在大纲，不写伏笔.md 。 4. 事实与读者认知：把关键事件生成到 timeline events 。同一事件同时写客观事实、读者截至 N 章已知内容和实际揭示状态；未来计划揭示章不得伪装成已发生事实。 5. 续写状态卡输入：准备当前位置、长期约束、活跃核心角色、近三章速记、下一章承诺和连贯性风险。上下文.md 由工具生成固定 7 栏，不把文风、文件索引、普通待办或质检计数塞进续写状态卡。 6. 执行初始化：按当前平台探测 Python 3（ python3 → python