LiPu-jpg/Openwrite

# 对话质量系统

用于分析角色对白、提取说话习惯、检查角色声音是否区分明显，以及识别 AI 味对话问题。

## 当前数据来源

对话分析不要只盯着对白片段本身。当前推荐读取顺序是：

1. `data/manuscript/arc_*/ch_*.md` — 实际章节正文
2. `src/characters/*.md` — 角色单源文档
3. `data/style/composed.md` — 当前作品风格约束
4. `src/outline.md` / canonical packet — 本章戏剧位置与章节目标

如果需要完整判断某章对白是否失真，优先结合 `review_chapter` 或章节 packet，而不是只看几行台词。

# 章节交付 DoG 查询

章节写作、评审和修订工具会生成：

`data/novels/{id}/data/dog/deliveries/{chapter}/dog-graph.json`

这张图查询六个阶段：`writing → review → revision → application → rereview → closure`。
它不替代 OpenWrite 的写章、六域累加评审或修订服务。

## 查询流程

1. 从最近一次 `novel_write_chapter`、`novel_review_chapter`、`novel_revision_*`
   或 `novel_task_get` 结果的 `dog_delivery.graphPath` 找到图；conductor 输出使用
   `dog_delivery_graph_path`。

# 拆书导入 DoG 验收

`conductor/smart_import.py` 完成导入后会生成 `dog-graph.json`。这张图只验收导入
结果，不负责写入章节、资产或大纲。

## 工作流

1. 从导入输出中找到 `data/novels/{id}/data/dog/imports/{IMPORT_ID}/dog-graph.json`。
2. 依次调用 `dog_validate`、`dog_create`、`dog_run`、`dog_wait`，直到终态。
3. 用 `dog_status` 查看 `manifest` 和每个 `chapter-ch_*` 节点的 evidence。
4. 根节点通过后，读取 manifest 的 `construction.nextActions`，再调用 Goethe 的规划和资产工具建立大纲、角色、世界观、进度和正典事件。
5. 资产/大纲建立完成后重新运行 `novel_review_chapter`，再用 `dog-review-query`
   查询六域评审和 37 个 legacy leaf。

# 分层评审 DoG 查询

这个 Skill 只查询 OpenWrite 已物化的 review-v2 artifact。OpenWrite 的
`novel_review_chapter` / conductor 是评审真源；DoG 读取 47 节点分层图：上下文、
六个质量域、硬门禁、确定性聚合和 37 个兼容查询 leaf。DoG 不调用评审模型。

## 工作流

1. 如果本轮还没有评审结果，先按 Dante 正常流程调用 `novel_review_chapter`。
2. 找到评审输出目录中的 `dog-graph.json`。graph 与 `review.json`、`context.json`、
   `domain-*.json`、`gate.json`、`aggregate.json` 和 `dim_01.json` …
   `dim_37.json` 在同一目录。
3. 读取 graph 后依次调用 `dog_validate`、`dog_create`、`dog_run`、`dog_wait`。
   所有节点均使用 programmatic `review-record` verifier；`dog_run` 后必须等到终态。

# 小说审查润色

通过 openwrite-bridge 的 `novel_*` 工具评审与修订。不要调用 Python 审查类或本地 33 维脚本。
正式评审是六域累加：质量分、覆盖率、硬门禁、交付状态分开判断；37 项只作展开查询。

## 触发条件

- "检查逻辑" / "逻辑检查"
- "润色" / "润色风格"
- "找伏笔漏洞" / "伏笔检查"
- "审查章节" / "审查"
- "风格问题"

## 工作流程

# Oh Story 去 AI 味

把 AI 味视为读感和叙事功能问题，不把词表命中当作错误。先确认用户要扫描、局部示范还是全文精修；默认先报告问题和样例，不擅自覆盖正文。

## 执行流程

1. 读取作者意图、人物声音、题材气质和当前段落功能，建立必须保留的内容。
2. 使用 `references/method.md` 扫描重复解释、句式齐整、对话同声、抽象判断和装饰性表达。
3. 按对读感的影响分级，优先修改高频且无功能的模式，不追求把所有句子变得不同。
4. 用最小改动恢复动作、选择、潜台词和节奏；结构或事实问题转交 `@oh-story-review`，不在润色中暗改。
5. 输出修改统计和少量前后对照；用户明确要求全文精修时才给完整候选稿。

## OpenWrite 边界

# Oh Story 长篇写作

先读取当前作品状态和用户本轮目标，再选择开书、补纲、写指定章、续写或修订。裸调用时只诊断所处阶段并给出下一步，不自动生成正文。

## 执行流程

1. 明确本轮交付范围和停靠点。用户没有指定正文数量时最多处理一章；只要求规划时停在候选或大纲交付。
2. 让 Goethe 处理读者契约、人物、世界、关系、全书阶段、卷纲和细纲；让 Dante 根据已确认资产写正文或做局部修订。
3. 使用 `references/method.md` 检查情绪承诺、主角代理权、冲突升级、剧情单元和章末钩子。
4. 写章前只召回不知道就会写错的资料：当前细纲、最近正文、出场人物状态、相关规则、伏笔和当前关注点。
5. 写完检查事实连续性、角色选择、信息变化、情绪结算和章节状态；结构问题优先于句子润色。

## OpenWrite 边界

# Oh Story 商业审稿

先确认审查对象、范围、目标读者和用户要“只诊断”还是“诊断后给修改稿”。默认只输出审查报告，不直接改动正文。

## 执行流程

1. 读取当前项目已确认资产、相关正文和审稿范围，先做缺失资料与冲突预检。
2. 使用 `references/method.md` 按阻断、严重、一般、润色四级检查，不让文风偏好掩盖事实或结构问题。
3. 每条发现给出位置或引文、问题、读者影响、证据和最小修复方向；证据不足时标记“需补充”。
4. 汇总最高优先级问题、可保留优点、建议修订顺序和仍需作者裁定的取舍。
5. 只有用户明确要求修改时才生成候选稿；涉及正式正文提交时继续走 OpenWrite workflow。

## OpenWrite 边界

# 真相文件验证系统

验证真相文件与章节内容的一致性，确保故事逻辑连贯。

## 核心概念

真相文件是记录世界当前状态的 Markdown 文件，包括：
- `current_state.md` - 世界当前状态
- `ledger.md` - 资源账本
- `relationships.md` - 角色关系矩阵

相关运行时文件（用于一致性校验）：
- `data/foreshadowing/dag.yaml` - 伏笔状态
- `data/hierarchy.yaml` 与 `data/compressed/` - 章节摘要与压缩信息

# 工作流管理

跟踪写章 → 评审 → 修订 → 应用 → 复评 → 交付。全部状态来自 OpenWrite 任务与章节工作简报，不要虚构本地阶段机，也不要调用已废弃的工作流命令。

## 作者可见阶段

1. 上下文预检 — `novel_context_preview`
2. 写章 — `novel_write_chapter` 或后台 `novel_task_create(type=chapter_write)` / `novel_multi_write`
3. 评审 — `novel_review_chapter` 或 `novel_task_create(type=chapter_review)`
4. 作者确认修订 — `novel_revisions_list` → apply / reject
5. 复评与交付 — 应用后复评；交付图为 writing → review → revision → application → rereview → closure

## 工具

# 伏笔管理系统

管理小说中的伏笔和悬念，确保故事线索连贯。

## 核心概念

伏笔（foreshadowing）是作者在前面章节埋下的线索，后面再回收。

**伏笔状态**：
- `埋伏` - 已埋下，等待回收
- `待收` - 即将回收
- `已收` - 已回收
- `废弃` - 放弃的伏笔

# 小说创作编排

通过 openwrite-bridge 的 `novel_*` 工具写章。不要调用 Python 模块、内置 Writer 类或已废弃的大纲命令。
所有正文写入走预览/确认门控；已有正文不得覆盖。

## 触发条件

- "写第X章" / "写章节"
- "生成章节" / "生成草稿"
- "续写" / "继续创作"
- "创作" + 章节相关

## 工作流程

# Oh Story 长篇拆解

把拆解视为只读、转化性的文学分析。先确认材料来源、用户有权使用的范围、章节边界和期望深度；材料不完整时标注限制，不用常识补齐原作事实。

## 执行流程

1. 先做作品概览与开篇样本，产出快速预览；除非用户明确要求完整拆解，否则在扩大到全书前停靠确认。
2. 使用 `references/method.md` 依次处理章节边界、开篇、逐章摘要、剧情聚合、人物设定、汇总报告和表达技法。
3. 每条硬事实标注可定位证据，区分原文事实、分析推断、迁移建议和待验证假设。
4. 把具体桥段抽象为功能位、情绪机制和输入输出条件，不生成可替代原作的逐章复述。
5. 数据量过大时分批推进并报告已覆盖范围、失败项和下一停靠点，不口头宣称全书完成。

## OpenWrite 边界

# Oh Story 长篇市场研究

把榜单当作有偏差的市场样本，不把排名本身当作选题答案。先确认平台、榜单口径、目标读者、题材范围、采样日期和作者自身优势。

## 执行流程

1. 收集可复核样本，并为每组数据记录平台、榜单类型、链接、访问日期、可见口径和样本量。
2. 使用 `references/method.md` 编码题材组合、情绪承诺、主角起点、核心机制、首个冲突、首次兑现和长期升级空间。
3. 先报告样本频次，再解释可能机制；把样本少的新组合标为信号，不直接称为趋势。
4. 输出多个选题候选，分别说明市场证据、作者适配、差异化、开篇验证方式、持续写作空间和风险。
5. 市场结论只作为 Goethe 的讨论输入，不直接改写项目资产。

## 数据边界

# 风格系统

## 核心原则

OpenWrite 不再内置任何参考作品风格库。  
风格来源只分三层：

```text
Layer 1: craft/                                  -> 通用技法与去模板化规则
Layer 2: data/novels/{id}/data/sources/{sid}/    -> 从用户提供文本提取出的 source pack
Layer 3: data/novels/{id}/src/**                 -> 本书确认版设定与约束
```

最终写作时，这三层会被合成为：

# 世界查询系统

把 `data/novels/{novel_id}/src/` 下的人物与世界实体文件作为唯一关系真源。Studio 拓扑和 ReAct 的 `get_world_relations` 必须调用同一个拓扑查询，不维护 `graph.yaml` 或第二套关系数据库。

## 查询

- 用 `query_world` 查询实体列表或详情。
- 用 `get_world_relations` 读取与 Studio 连续性页面同源的节点和边。
- Studio 关系拓扑支持按节点名称、ID、类型、摘要和关系文字搜索；命中节点会保留一跳相邻节点和连线作为上下文。
- ReAct 没有第二套拓扑搜索索引；需要搜索时读取 `get_world_relations` 后在同一份节点/边结果中按上述字段过滤。
- 先用 ID 定位；用户只提供名称时允许按 front matter 名称或 Markdown H1 定位。

兼容读取以下关系来源：

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 查设定

接到已有 `novel_*`。人物、地点、世界观以 OpenWrite 资产为准。

1. `novel_assets_list` 列出人物/世界资产（含名称与别名）。
2. 指定实体用 `novel_asset_read`。
3. 按名称或别名找不到时 `novel_search`（scope 可 `assets`）。
4. 关系与状态漂移用 `novel_continuity`。

向作者报告规范名、别名、摘要。改设定走 `novel_structured_change_plan(change_kind="asset")`；普通讨论不得写入。

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 对话质量系统

用于分析角色对白、提取说话习惯、检查角色声音是否区分明显，以及识别 AI 味对话问题。

## 当前数据来源

对话分析不要只盯着对白片段本身。当前推荐读取顺序是：

1. `data/manuscript/arc_*/ch_*.md` — 实际章节正文
2. `src/characters/*.md` — 角色单源文档
3. `data/style/composed.md` — 当前作品风格约束
4. `src/outline.md` / canonical packet — 本章戏剧位置与章节目标

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 章节交付 DoG 查询

章节写作、评审和修订工具会生成：

`data/novels/{id}/data/dog/deliveries/{chapter}/dog-graph.json`

这张图查询六个阶段：`writing → review → revision → application → rereview → closure`。
它不替代 OpenWrite 的写章、六域累加评审或修订服务。

## 查询流程

1. 从最近一次 `novel_write_chapter`、`novel_review_chapter`、`novel_revision_*`

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 拆书导入 DoG 验收

`conductor/smart_import.py` 完成导入后会生成 `dog-graph.json`。这张图只验收导入
结果，不负责写入章节、资产或大纲。

## 工作流

1. 从导入输出中找到 `data/novels/{id}/data/dog/imports/{IMPORT_ID}/dog-graph.json`。
2. 依次调用 `dog_validate`、`dog_create`、`dog_run`、`dog_wait`，直到终态。
3. 用 `dog_status` 查看 `manifest` 和每个 `chapter-ch_*` 节点的 evidence。
4. 根节点通过后，读取 manifest 的 `construction.nextActions`，再调用规划和资产工具建立大纲、角色、世界观、进度和正典事件。
5. 资产/大纲建立完成后重新运行 `novel_review_chapter`，再用 `dog-review-query`

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 分层评审 DoG 查询

这个 Skill 只查询 OpenWrite 已物化的 review-v2 artifact。OpenWrite 的
`novel_review_chapter` / conductor 是评审真源；DoG 读取 47 节点分层图：上下文、
六个质量域、硬门禁、确定性聚合和 37 个兼容查询 leaf。DoG 不调用评审模型。

## 工作流

1. 如果本轮还没有评审结果，先按 OpenWrite 写作流程调用 `novel_review_chapter`。
2. 找到评审输出目录中的 `dog-graph.json`。graph 与 `review.json`、`context.json`、
   `domain-*.json`、`gate.json`、`aggregate.json` 和 `dim_01.json` …
   `dim_37.json` 在同一目录。

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 导出

接到已有 `novel_*`。成稿导出与会话日志下载不是同一条命令。

1. `novel_export_preflight`：阅读顺序、结构缺陷、写作目标、评审新鲜度、正文接纳、阻断项与警告。
2. 向作者说明 `backup`（可带警告下载）与 `delivery`（门禁阻断则不可交付）。
3. 作者确认后 `novel_export`，原样传入同一 `format`、`purpose` 与 `preflight_revision`。

不要用宿主 `/export` 下载会话日志来代替成稿。完整项目档案走 `novel_project_archive_action`。

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 查伏笔

接到已有 `novel_*`。伏笔真源是 OpenWrite DAG 与章节工作简报。

1. `novel_status` 看全书待办。
2. 当前章用 `novel_chapter_work`：到期 `must_resolve`、超期 `overdue`、待埋入 `to_plant`。
3. 全书未回收与漂移用 `novel_continuity`。

向作者报告分类清单，不要输出内部 JSON 当主界面。写入走 `novel_structured_change_plan(change_kind="foreshadowing")`；仅在作者本轮已授权精确变更时才用 `novel_foreshadowing`。

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 伏笔管理系统

管理小说中的伏笔和悬念，确保故事线索连贯。

## 核心概念

伏笔（foreshadowing）是作者在前面章节埋下的线索，后面再回收。

**伏笔状态**：
- `埋伏` - 已埋下，等待回收
- `待收` - 即将回收
- `已收` - 已回收

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 写法记忆

接到已有 `novel_*`。风格、成功钩子和作者偏好是当前 Workspace 作品资产，不是会话本地文件，也不是第二套 RAG / lorebook。

## 读取

1. `novel_status` 确认当前作品。
2. 风格与提取源：`novel_source_action`（`status_v2` / `profile_v2`）。
3. 已登记钩子：`novel_assets_list`，必要时 `novel_asset_read`。

没有 Workspace（session cwd 缺失）时这些工具返回 `WORKSPACE_CONTEXT_MISSING`，不要改写全局或别的项目。

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 小说创作编排

通过 openwrite-bridge 的 `novel_*` 工具写章。不要调用 Python 模块、内置 Writer 类或已废弃的大纲命令。
所有正文写入走预览/确认门控；已有正文不得覆盖。

## 触发条件

- "写第X章" / "写章节"
- "生成章节" / "生成草稿"
- "续写" / "继续创作"
- "创作" + 章节相关

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 小说审查润色

通过 openwrite-bridge 的 `novel_*` 工具评审与修订。不要调用 Python 审查类或本地 33 维脚本。
正式评审是六域累加：质量分、覆盖率、硬门禁、交付状态分开判断；37 项只作展开查询。
`novel_config.yaml` 的 `form: web_novel` 时，情节/节奏域额外检查钩子、黄金三章、追读力；这些准则 `max=0`，不另起一套评分。黄金三章只适用于第 1–3 章。

## 触发条件

- "检查逻辑" / "逻辑检查"
- "润色" / "润色风格"
- "找伏笔漏洞" / "伏笔检查"
- "审查章节" / "审查"

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# Oh Story 去 AI 味

把 AI 味视为读感和叙事功能问题，不把词表命中当作错误。先确认用户要扫描、局部示范还是全文精修；默认先报告问题和样例，不擅自覆盖正文。

## 执行流程

1. 读取作者意图、人物声音、题材气质和当前段落功能，建立必须保留的内容。
2. 使用 `references/method.md` 扫描重复解释、句式齐整、对话同声、抽象判断和装饰性表达。
3. 按对读感的影响分级，优先修改高频且无功能的模式，不追求把所有句子变得不同。
4. 用最小改动恢复动作、选择、潜台词和节奏；结构或事实问题转交 `@oh-story-review`，不在润色中暗改。
5. 输出修改统计和少量前后对照；用户明确要求全文精修时才给完整候选稿。

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# Oh Story 长篇拆解

把拆解视为只读、转化性的文学分析。先确认材料来源、用户有权使用的范围、章节边界和期望深度；材料不完整时标注限制，不用常识补齐原作事实。

## 执行流程

1. 先做作品概览与开篇样本，产出快速预览；除非用户明确要求完整拆解，否则在扩大到全书前停靠确认。
2. 使用 `references/method.md` 依次处理章节边界、开篇、逐章摘要、剧情聚合、人物设定、汇总报告和表达技法。
3. 每条硬事实标注可定位证据，区分原文事实、分析推断、迁移建议和待验证假设。
4. 把具体桥段抽象为功能位、情绪机制和输入输出条件，不生成可替代原作的逐章复述。
5. 数据量过大时分批推进并报告已覆盖范围、失败项和下一停靠点，不口头宣称全书完成。

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# Oh Story 长篇市场研究

把榜单当作有偏差的市场样本，不把排名本身当作选题答案。先确认平台、榜单口径、目标读者、题材范围、采样日期和作者自身优势。

## 执行流程

1. 收集可复核样本，并为每组数据记录平台、榜单类型、链接、访问日期、可见口径和样本量。
2. 使用 `references/method.md` 编码题材组合、情绪承诺、主角起点、核心机制、首个冲突、首次兑现和长期升级空间。
3. 先报告样本频次，再解释可能机制；把样本少的新组合标为信号，不直接称为趋势。
4. 输出多个选题候选，分别说明市场证据、作者适配、差异化、开篇验证方式、持续写作空间和风险。
5. 市场结论只作为规划阶段的讨论输入，不直接改写项目资产。

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# Oh Story 长篇写作

先读取当前作品状态和用户本轮目标，再选择开书、补纲、写指定章、续写或修订。裸调用时只诊断所处阶段并给出下一步，不自动生成正文。

## 执行流程

1. 明确本轮交付范围和停靠点。用户没有指定正文数量时最多处理一章；只要求规划时停在候选或大纲交付。
2. 先处理读者契约、人物、世界、关系、全书阶段、卷纲和细纲，再根据已确认资产写正文或做局部修订。
3. 使用 `references/method.md` 检查情绪承诺、主角代理权、冲突升级、剧情单元和章末钩子。
4. 写章前只召回不知道就会写错的资料：当前细纲、最近正文、出场人物状态、相关规则、伏笔和当前关注点。
5. 写完检查事实连续性、角色选择、信息变化、情绪结算和章节状态；结构问题优先于句子润色。

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# Oh Story 商业审稿

先确认审查对象、范围、目标读者和用户要“只诊断”还是“诊断后给修改稿”。默认只输出审查报告，不直接改动正文。

## 执行流程

1. 读取当前项目已确认资产、相关正文和审稿范围，先做缺失资料与冲突预检。
2. 使用 `references/method.md` 按阻断、严重、一般、润色四级检查，不让文风偏好掩盖事实或结构问题。
3. 每条发现给出位置或引文、问题、读者影响、证据和最小修复方向；证据不足时标记“需补充”。
4. 汇总最高优先级问题、可保留优点、建议修订顺序和仍需作者裁定的取舍。
5. 只有用户明确要求修改时才生成候选稿；涉及正式正文提交时继续走 OpenWrite workflow。

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 看进度

接到已有 `novel_*`。不要另建进度文件或阶段机。

1. `novel_status`：当前作品、阶段、资产缺口、待确认项。
2. 需要章级细节时 `novel_chapter_work`。
3. 后台工作 `novel_tasks_list`；进行中或待确认的任务 `novel_task_get`。

向作者报告：当前章、正文是否存在、评审是否新鲜、任务 phase、伏笔到期/超期/待埋入计数。不要把内部 JSON 当主界面。

细则见 workflow-manager。

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 审这一章

接到已有 `novel_*`。正式评审是六域累加；37 项只作展开查询。
网文项目（`form: web_novel`）另附钩子 / 黄金三章 / 追读力可选准则，不计分。

1. `novel_outline_read` 与 `novel_status` 确认章节。
2. `novel_chapter_work` 读取正文 revision、评审新鲜度、本章伏笔义务。
3. 尚无正文则提示先写章，不要空审。评审 stale 时先复评。
4. `novel_review_chapter` 跑六域评审。
5. 向作者报告质量分、覆盖率、门禁、交付状态，以及带正文证据的问题。

作者要改稿时转到 /revise-span。查询已物化评审图用 dog-review-query，不要让 DoG 再调模型。细则见 novel-reviewer。

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 改这段

接到已有 `novel_*`。改稿只走修订提案，不直接整章覆盖。

1. 选区扩写/缩写/去 AI 味：`novel_revision_create_selection`。
2. 按审稿改：`novel_revision_create_from_review`（带 issue 与期望 revision）。
3. 展示 before/after；作者确认后 `novel_revision_apply`（可带 `selected_hunk_ids`）。
4. 提案 `source_revision` 与当前正文不一致时拒绝覆盖，改为 `novel_revision_regenerate` 或重新预览。
5. 应用后必须 `novel_review_chapter` 复评。

手工/润色类正文预览用 `novel_document_change_plan`。没有当前评审时，按审稿改失败闭合。细则见 novel-reviewer。

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 风格系统

## 核心原则

OpenWrite 不再内置任何参考作品风格库。  
风格来源只分三层：

```text
Layer 1: craft/                                  -> 通用技法与去模板化规则
Layer 2: data/novels/{id}/data/sources/{sid}/    -> 从用户提供文本提取出的 source pack
Layer 3: data/novels/{id}/src/**                 -> 本书确认版设定与约束
```

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 真相文件验证系统

验证真相文件与章节内容的一致性，确保故事逻辑连贯。

## 核心概念

真相文件是记录世界当前状态的 Markdown 文件，包括：
- `current_state.md` - 世界当前状态
- `ledger.md` - 资源账本
- `relationships.md` - 角色关系矩阵

相关运行时文件（用于一致性校验）：

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 工作流管理

跟踪写章 → 评审 → 修订 → 应用 → 复评 → 交付。全部状态来自 OpenWrite 任务与章节工作简报，不要虚构本地阶段机，也不要调用已废弃的工作流命令。

## 作者可见阶段

1. 上下文预检 — `novel_context_preview`
2. 写章 — `novel_write_chapter` 或后台 `novel_task_create(type=chapter_write)` / `novel_multi_write`
3. 评审 — `novel_review_chapter` 或 `novel_task_create(type=chapter_review)`
4. 作者确认修订 — `novel_revisions_list` → apply / reject
5. 复评与交付 — 应用后复评；交付图为 writing → review → revision → application → rereview → closure

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 世界查询系统

把 `data/novels/{novel_id}/src/` 下的人物与世界实体文件作为唯一关系真源。Studio 拓扑和 ReAct 的 `get_world_relations` 必须调用同一个拓扑查询，不维护 `graph.yaml` 或第二套关系数据库。

## 查询

- 用 `query_world` 查询实体列表或详情。
- 用 `get_world_relations` 读取与 Studio 连续性页面同源的节点和边。
- Studio 关系拓扑支持按节点名称、ID、类型、摘要和关系文字搜索；命中节点会保留一跳相邻节点和连线作为上下文。
- ReAct 没有第二套拓扑搜索索引；需要搜索时读取 `get_world_relations` 后在同一份节点/边结果中按上述字段过滤。
- 先用 ID 定位；用户只提供名称时允许按 front matter 名称或 Markdown H1 定位。

Language: follow the author's current conversation language for responses and help; preserve the manuscript language. Translate these instructions when presenting them.

# 写下一章

接到已有 `novel_*`。已有正文不得覆盖。

1. `novel_status` 看阶段与待确认项；`outline_scope` 待确认时先让作者确认大纲范围。
2. `novel_outline_read` 定位章纲：未指定则取大纲顺序中最早尚无正文的章。
3. `novel_context_preview` 预检上下文包。
4. `novel_chapter_work` 读取本章到期/超期/待埋入伏笔与字数目标。
5. `novel_write_chapter` 写下一章或指定章。
6. 草稿出来后暂停，请作者选择：通过进入评审、按意见重写、或到创作页手工编辑。

资产不齐时先规划补齐，不切换会话。节拍与审核口令见 novel-creator。

# DoG(DAG of Goals)使用说明

> DoG = **DAG of Goals**(目标的有向无环图):把一个大目标拆成一棵"目标树",每个小目标可以被单独判定,系统逐项判定后汇总。
> 本说明对应 **dsh-dog v1.2.0**(协议 schemaVersion `0.9`);协议字段如下文所述,产品版本演进不改协议号。
> **需要完整操作手册(全部工具字段、状态语义、错误诊断、最佳实践)请读 `docs/agent-guide.md`。**

## 0. 什么时候使用这个 skill(什么时候不用)

**用**:你的任务目标是一句"非形式化"的话——"做得高不高/好不好"没有唯一判准,不能一眼说"做到了":
- "做一份高质量的答辩 PPT"
- "写一篇真正有质量的文章"(不是字数够、没有错别字那种)
- "重写一段可读性强的说明"

**不用**:能一条规则直接判断的("运行测试""改这个文件名")。