/chapter-outline-builder

name: chapter-outline-builder
title: 章纲总控
description: 当用户需要把小说大纲、分卷大纲、上一章状态或一个章节灵感整理成可写作的单章章纲时使用；适用于章纲、单章细纲、章节推进、下一章怎么写、这一章怎么写等请求；不用于全书大纲或正文润色。

章纲总控

核心原则

章纲是小说的单章执行单元。它要回答四件事：这一章让读者感受到什么、剧情发生什么变化、读者记住什么、为什么继续看下一章。

完整输出必须遵循上级目录的 `CHAPTER_OUTLINE_STANDARD.md`。旧称“细纲”的单章内容统一升级为“章纲”，文件名使用 `章纲-第001章.md` 这类格式。

调用顺序

始终按顺序调用或手动执行以下技能。用户已经提供的部分可以复用，但最终必须进入 `chapter-outline-assembler` 汇总。

| 顺序 | 技能 | 产出 | |---|---|---| | 1 | `chapter-attribute-positioning` | 情绪标签、章节属性、主线承接、主线推进、人物变化、追读目的 | | 2 | `chapter-keyword-conditions` | 浓缩剧情、关键词、必要条件、必须插入的信息 | | 3 | `chapter-four-beat-flow` | 开篇入戏、中段冲突、核心爆点、强钩收尾 | | 4 | `chapter-emotion-curve` | 开局情绪、中段变化、峰值爆发、结尾沉淀 | | 5 | `chapter-visual-detail` | 环境细节、动作微细节、信息暗线细节 | | 6 | `chapter-foreshadow-hook` | 回收旧伏笔、预埋新伏笔、结尾强钩子 | | 7 | `chapter-outline-assembler` | 完整章纲和写作检查清单 |

必要输入

• 上一章结尾状态
• 当前大纲阶段目标
• 本章想完成的剧情进度
• 主角当前处境和情绪
• 需要回收或埋下的伏笔
• 下一章希望读者期待什么

缺失信息处理

缺失信息不多时，最多问 3 个短问题。用户想快速推进时，直接做“明确标注的假设”，不要卡住。

优先补齐这三类信息：

1. 上一章结尾留下了什么问题。 2. 本章必须发生什么变化。 3. 结尾要让读者期待什么。

连续章节处理

用户要求连续生成多章章纲时，逐章重复完整流程。每章都要保留：

• 上一章钩子的承接。
• 本章的独立变化。
• 下一章的新钩子。
• 旧伏笔和新伏笔的交接关系。

如果你在本轮或上一轮主动建议分成两章章纲，这次章纲生成就按完整流程写出这两章章纲，各一份，后一章承接前一章钩子。「下一章交接」不能代替第 2 章章纲。不要等用户再说「连续生成」。用户拒绝该建议、建议不是两章、或明确只要一章时，不要用这段。

不要把多章写成一个拉长的剧情摘要；每章都必须有自己的情绪标签、章节属性、核心记忆点和追读理由。

最终交付要求

输出中文章纲，必须包含：

• 基础信息和文件命名
• 上章承接
• 本章一句话目标
• 情绪标签和章节属性
• 本章推进定位
• 核心事件因果链
• 浓缩剧情和关键词
• 四段式章纲
• 情绪曲线
• 爽点与看点
• 关键信息与扩写方式
• 画面细节
• 伏笔和钩子
• 出场角色与状态变化
• 设定/世界观/道具更新
• 写作约束
• 下一章交接
• 写作检查清单

质量门

交付前逐项检查：

• 三行内能入戏。
• 本章至少有一个明确变化。
• 有一个核心记忆点。
• 至少有一个动作微细节。
• 至少回收一个旧信息或旧问题。
• 至少埋下一个新信息或新问题。
• 结尾有明确追读钩子。
• 浓缩剧情、关键词、必要条件能支撑正文写作。
• 关键信息与扩写方式已经区分“传递什么信息”和“如何写成场景”。
• 上章承接和下一章交接都存在，连续章节不会断档。
• 角色入场状态、结束状态和关系变化能支持后续状态更新。

边界

• 不直接写正文，除非用户明确要求。
• 不把解释说明写成整章主体。
• 不让过渡章变成“什么都没发生”。
• 浓缩剧情和必要条件不清楚时，不进入四段式拆分。
• 除非用户明确要求安静收束，否则不要用睡觉、离场、完全解决作为结尾。
• 一章只保留一个主属性，不要同时承担铺垫、高潮、反转、过渡等所有功能。