# Novel Drafting > Use when 中文小说项目已经具备调研文件，并需要按章节起草、经过审查闸门、执行连续性检查或从阻塞状态恢复起草 - Skill: `smter/novel-drafting` (Agent Skill, multi-file: 34 files) - Install (CLI): `npx skillmds@latest add smter/novel-drafting` - Raw SKILL.md: https://api.skillmd.com/api/skills/smter/novel-drafting/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: smter (https://skillmd.com/u/smter) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/smter/novel-drafting --- # 小说起草 ## 概述 验证调研阶段产物，从任意中断点恢复进度，并通过子 agent 循环执行章节写作与审查，直到计划中的整本小说完成且所有审查闸门通过。 流程推进受 lint 监督。控制器不能仅凭聊天中的口头声明推进起草状态；它必须读取项目产物并运行起草验证器。 ## 何时使用 - 项目状态为 `research_complete` 或 `draft_blocked` - 所有必需调研文件均存在且内容充分 - 用户希望开始或继续写章节 - 在审查通过前，起草流程必须保持阻塞 ## 入口闸门 开始写作前，检查： - `00-project/workflow-status.md` 的 status 为 `research_complete` 或 `draft_blocked` - `00-project/workflow-status.md` 的 current stage 与起草阶段兼容 - `00-project/success-criteria.md` - `20-story/characters/` - `20-story/plot-outline.md` - `20-story/foreshadowing.md` - `30-draft/chapter-plan.md` 如果任一项缺失或内容薄弱，立即停止并报告阻塞。 ## 验证闸门 在推进工作流状态之前，对小说根目录运行起草验证器： ```bash node --experimental-strip-types /scripts/validate-drafting-project.mts --project-root --mode Entry node --experimental-strip-types /scripts/validate-drafting-project.mts --project-root --mode Progress node --experimental-strip-types /scripts/validate-drafting-project.mts --project-root --mode Completion node --experimental-strip-types /scripts/validate-drafting-project.mts --project-root --mode WordCount node --experimental-strip-types /scripts/validate-drafting-project.mts --project-root --mode WordCount --chapter chapter-03 ``` 使用方式： - `Entry`：起草开始或恢复前 - `Progress`：writer 或 reviewer 的输出改变当前章节状态后 - `Completion`：设置 `draft_complete` 或 `Next Allowed Skill: novel-delivery` 之前 - `WordCount`：只做字数检查，不推进工作流，也不检查 review / completion gate `WordCount` 规则： - 不带 `--chapter` 时，检查所有已有章节文件的章节字数是否落在目标区间内 - 带 `--chapter chapter-XX` 或 `--chapter 3` 时，只检查指定章节 - `WordCount` 不检查全书完成状态；全书总字数仍由 `Completion` 负责 字数验证优先规则： - 当 agent 只需要确认章节或单章字数是否达标时，必须优先运行 `WordCount` 模式 - 不要在聊天中自行估算字数，也不要临时搓新的统计命令来替代 validator - 只有在调试 `check-word-count.mts` 本身时，才允许绕开这个入口 验证器输出具有最终权威性。只要失败，就不得推进流程。 ## 项目根目录识别 本 skill 中的所有路径都应视为相对于小说项目根目录，而不是默认相对于工作区根目录。 在读写 `00-project`、`30-draft`、`40-review` 或 `50-delivery` 之前，按以下规则识别根目录： - 如果当前目录已经包含 `00-project/workflow-status.md`，就使用当前目录 - 否则，如果当前目录下恰好只有一个子级书籍目录包含 `00-project/workflow-status.md`，就使用那个子目录 - 否则，停止并报告项目根目录存在歧义 一旦识别出有效的小说根目录，就不要继续在同级目录树中反复搜索。 ## 恢复逻辑 检查： - `30-draft/chapters/` - `30-draft/continuity/` - `40-review/chapter-reviews/` 从第一个缺失、审查未通过或尚未标记为通过的章节继续。 ## Subagent 思维链模板 Writer 和 Reviewer 子代理在执行起草或审查前，按以下模板推进： 1. **上下文理解** — 本章在全书的位置？本章的核心目标是什么？出场角色有哪些？ 2. **约束回顾** — 本章需要遵守的风格约束（对照 `10-research/style-research.md` 和 `references/style-analysis-guide.md` 的四层宪章）？角色声线要求（对照角色卡）？伏笔/揭示要求（对照 `20-story/foreshadowing.md`）？ 3. **执行方案** — 拟写几幕？每幕的起止和功能？每幕关键场景？ 4. **自检** — 产出是否覆盖上述所有要求？是否对照 `lint-contract.md` 的起草自检清单逐项通过？ subagent 在实际产出之前，先输出以上四步的简短摘要。 ## Writer 子 Agent 契约 只向 writer 提供： - `00-project/project-brief.md` - `10-research/style-research.md` - 此外，Writer 在需要处理风格一致性时可查阅 `references/style-analysis-guide.md` 的风格复现宪章。 - `20-story/characters/` - `20-story/plot-outline.md` - `20-story/foreshadowing.md` - `30-draft/continuity/story-state.md` - 必要时最近的已批准 `30-draft/continuity/chapter-XX-state.md` - `30-draft/chapter-plan.md` 中当前章节的目标 writer 输出当前章节草稿，并写出当前章节的 continuity state。 **Writer 硬性要求：** - 对话场景中，每段对话必须至少体现一种潜文本动词（暴露/操控/维护）。对照 `references/theory/mckee-dialogue.md` 的三大功能和潜文本动词体系检查。 - 起草时对照 `references/style-analysis-guide.md` 的四层宪章（神/骨/皮/肉）逐层校验风格一致性。 ## Reviewer 子 Agent 契约 reviewer 需要检查： - 章节字数是否符合目标 - 是否符合当前章节目标 - 是否符合整体大纲 - 人物一致性 - 风格一致性（如有明确风格约束，对照 `style-research.md` 和 `style-analysis-guide.md` 的风格四层框架检查） - 是否出现不允许的提前揭示 - 与前文章节的连续性 - 与 `story-state.md` 和最近已批准 continuity state 的一致性 - 节奏与可读性 - 角色行为一致性：对照 `references/theory/mckee-character.md` 的六维度体系检查角色行为是否与角色卡定义一致，是否存在矛盾。确认本角色在本章中是否有可感知的弧光推进 - 叙事结构校验：本章是否达成 `30-draft/chapter-plan.md` 中的本章目标？是否正确承接前章事件、为后章铺垫线索？ 当 reviewer 或 controller 只需要确认字数是否达标，而不是做完整 `Progress` / `Completion` 验证时： - 运行 `node --experimental-strip-types /scripts/validate-drafting-project.mts --project-root --mode WordCount` - 如需点查单章，运行 `node --experimental-strip-types /scripts/validate-drafting-project.mts --project-root --mode WordCount --chapter chapter-XX` - 不要自行实现字数统计逻辑 reviewer 必须将结构化审查文件写入 `40-review/chapter-reviews/chapter-XX-review.md`，并返回 `通过` 或 `不通过`。 reviewer 不负责重写章节正文。 reviewer 还必须确认当前章节的 `30-draft/continuity/chapter-XX-state.md` 能准确记录： - 新确认事实 - 人物认知变化 - 人物认知变化的触发依据 - 已触发的一次性事件 - 下一章不得违背的连续性约束 `Character Knowledge Changes` 与 `story-state.md` 的 `Character Knowledge` 必须使用： - `<角色名> | <事实> | unknown|suspected|confirmed | source=chapter-XX` 若某条知识状态写为 `confirmed`，`chapter-XX-state.md` 中必须提供对应的： - `<角色名> | <事实> | basis=<本章内的触发依据>` `story-state.md` 中的 `One-Time Events Consumed` 必须显式写明来源章节，格式固定为： - `: chapter-XX` `chapter-XX-state.md` 中的 `One-Time Events Triggered` 也必须结构化记录，格式固定为： - ` | consumed=yes` - ` | consumed=no` 如果某条事件标记为 `consumed=yes`，则 `story-state.md` 中必须有同名归档条目。 ## 修订循环 - 若 review 返回 `不通过`，只把审查结论回传给 writer。 - 同一章节最多尝试 3 次草稿。 - 第 3 次仍失败时，停止并标记 `draft_blocked`。 对应要求： - 若 review 返回 `不通过`，只把审查结论回传给 writer - 同一章节最多尝试 3 次草稿 - 第 3 次仍失败时，停止并标记 `draft_blocked` ## 状态更新 起草开始时： - 将状态设为 `draft_in_progress` 某章节失败次数过多时： - 将状态设为 `draft_blocked` - 列出被阻塞的章节与原因 当所有章节和最终审查都通过时： - 将状态设为 `draft_complete` ## 全书完成闸门 最后一个计划章节通过后，执行整书级审查： - 将已完成章节与 `30-draft/chapter-plan.md` 对比 - 将 `30-draft/continuity/story-state.md` 与已通过章节对齐 - 验证每个 `40-review/chapter-reviews/chapter-XX-review.md` 都已通过 - 将总字数与目标区间对比 只有在上述检查都通过后，才能设置 `draft_complete`。 ## 推进前置条件 推进流程前必须确认： - 有具体、明确的章节完成证据（非模糊的"差不多了"） - 当前章节审查意见已全部解决（非"后面再改"） - 伏笔揭示时序与大纲一致（非提前放出） - 重试次数未超限额（当前章节重试上限：3 次） ## 常见自我说服 | 借口 | 现实 | |------|------| | "缺一个文件不该妨碍创作" | 缺文件就说明契约不完整。 | | "审查放松一点没关系，后面章节会补救" | 后续章节只会放大连续性损伤。 | | "再多试一次也没坏处" | 无限重试会掩盖真正阻塞的工作。 | ## 下一步 在 `draft_complete` 之后，下一个允许使用的 skill 是 `novel-delivery`。 验证器模式和强制产物检查见 `lint-contract.md`。