@oh-story/dsh 0.1.14 → 0.1.16

package/lib/oh-story/skills/story-setup/references/agent-references/style-genre-modules.md

@@ -77,7 +77,7 @@
 ## 幽默
 
 ### 核心原则
-幽默是压力释放器，不是笑话delivery。最好的幽默来自角色试图维持尊严/权威/冷静，但现实不配合。
+幽默通过角色遭遇释放压力，不能只靠插入笑话。最好的幽默来自角色试图维持尊严/权威/冷静，但现实不配合。
 
 ### 幽默来源
 - 角色的尴尬（想装酷但翻车）
@@ -456,7 +456,7 @@
 
 ## 创作思路与开篇设计
 
-- 创作思路三步法：确定主角身份 -> 匹配金手指类型 -> 设定开局环境 -> 设立意象（标签）
+- 创作思路四步法：确定主角身份 -> 匹配金手指类型 -> 设定开局环境 -> 设立意象（标签）
 - 意象 = 给人物和剧情贴标签提升深度
 - 开篇不需要写冲突，可以写环境，关键是流畅，把所有信息带出来
 - 不要通过旁白介绍背景，多通过对话把信息掺杂在里面
@@ -474,7 +474,7 @@
 - 多通过对话传递信息，少用旁白介绍背景
 - 给出金手指后要有即时变化——让读者看到变化的过程
 - 金手指要在主角积极应对危机但能力不足时才来——这样主角不是废物
-- 什么身份做什么事：马奴不配有道德，步子太大 = 结构破坏
+- 身份限制行动条件：低位角色要越级行事，先铺资源、动机与代价，避免行动脱离处境
 - 写大剧情时检查：主角目前的等级、身份和资源是否够格？
 
 ---

package/lib/oh-story/skills/story-setup/references/agent-references/style-resolution.md

@@ -1,10 +1,10 @@
 # 文风与参考冲突裁决
 
-写正文、改写、去 AI 味和审稿都先做这一步；inline 与 agent 用同一份裁决。无需另建画像或要求作者填写配置。
+写正文、改写、去 AI 味和审稿前，先确定本次生效的文风要求。主会话与子代理共用本次裁决。
 
-## 按维度取值，不把整份文件互相覆盖
+## 按表达维度确定优先级
 
-表达选择按以下顺序取第一个明确、适用的要求：**当前请求 > 本书文风/设定 > 本书 active 作者记忆 > 题材、流程、全局 active 记忆 > 主对标文风 > 题材包与通用 references 默认值**。未声明的维度才向下补齐；本书例外不撤销全局习惯，临时要求不写回长期记忆。
+表达选择按以下顺序取第一个明确、适用的要求：**当前请求 > 本书文风/设定 > 写作流程传入的适用偏好 > 主对标文风 > 题材包与通用 references 默认值**。传入偏好中，本书要求优先于题材、流程和全局要求；未声明的维度才向下补齐。
 
 句长、视角、标点、对话落法、情绪直写、修辞、叙述者评论和收尾方式都是表达维度。reference 中的“必须”“禁用”“最高优先级”、示例和检测阈值不使默认写法升级为作者不可覆盖的规则。主对标的低置信观察不压过作者的明确选择。
 
@@ -14,7 +14,7 @@
 
 1. 从本次正文路径确定书目录（长篇为 `正文/` 的父目录，短篇为 `正文.md` 所在目录）。读该书 `设定/文风.md`；短篇同时读 `设定.md` 的文风约定。无文件就继续，不建占位文件、不猜其他书。文风无最低字数限制，一句可执行的偏好也有效；空白、纯标题、待补充不算。
 2. `_文风摘要.md` 只辅助定位，不替代全文。当前会话已读全文时无需反复读；摘要与全文不一致用全文，不让旧摘要压过作者的新修改。
-3. 有作者记忆时 query，显式传当前书名、已知题材和流程以及需要的 kind，避免只取到 global；没有就跳过。只用 active；同一维度窄范围覆盖宽范围，不拼成同时满足的清单。无法判定的同范围冲突才问作者，已能按优先级解决的不询问。
+3. 复用调用方传入的适用偏好与文风裁决，同一表达维度由窄到宽取值；同范围冲突不明才问作者。独立调用没有传入结果时，按当前请求与本书文风继续。
 4. 在现有 prompt 填 `style_resolution`：本次生效的表达要求及来源、被覆盖的默认条款、必须保留的事实/信息边界；只列与任务有关的冲突，无冲突可写“按本书文风”。原样传给正文、去味和文字 reviewer，并传文风全文路径。同批复用，当前请求或文风变动时更新。单独调用去味/审稿也执行本步骤，不靠上次会话的记忆。
 
 ## 检测器如何服从裁决
@@ -24,4 +24,4 @@
 - 本书文风明确允许某种停顿标点时，可登记 `——` 或 `……`；具体修辞登记完整的获准原句，不能登记“不是”“没有”等泛词来关闭整类检查。
 - 每项用上一行 `# 来源：…；用途：…` 说明当前请求或文风依据。只为执行作者已明确的选择登记，不因脚本报警自动放行。当前请求禁止某写法时移除相冲突的豁免；一次性保留只登记该句，不推断长期习惯。
 - 深扫、标点整理和写后/下一章检查读取同一白名单。豁免只影响对应字面片段的风格检查；同一行其他问题照报，事实、字数、占位、工程词、截断和文件结构检查不豁免。
-- 所选 Gate 仍执行：检查该写法是否重复、冗余、破坏节奏或越过信息边界；有这些具体问题才改。裁决与发现可简短写在正常交付报告中，不写进小说正文。
+- 当前任务的审查门禁（Gate）仍执行，检查重复、冗余、节奏和信息边界问题。裁决与发现写在交付报告中，不写进小说正文。

package/lib/oh-story/skills/story-setup/references/agent-references/writing-craft.md

@@ -1,6 +1,6 @@
 # 写作技法：可执行指令集
 
-> 写作全程参考。对话怎么写见 dialogue-mastery.md，开篇设计见 opening-design.md，章节格式按长篇 long-format.md 或短篇 format-and-structure.md。
+> 写作全程参考。对话怎么写见 dialogue-mastery.md，开篇设计见 opening-design.md；正文格式按调用方指定的格式文件与本书约定执行。
 
 ---
 
@@ -44,32 +44,33 @@
 
 ---
 
-## 2. 贯穿道具系统（三次出现规则）
+## 2. 贯穿道具：随情节改变意义
 
 ### 规则
 
-每个叙事单元（短篇/长篇卷）设计 1-2 个贯穿道具。每个物件必须出现 3 次，每次意义不同。
+物件能承载关系或处境变化时，可选用贯穿道具；每次重现都应增加信息或改变意义，次数与位置随剧情单元调整。
 
-### 三次出现编排
+### 三次出现示例
 
 | 出现时机 | 功能 | 示例 |
 |----------|------|------|
-| 第 1 次出现（前 1/4） | 建立初始意义 | 金锁 = 姐姐送的生日礼物（温暖） |
+| 第 1 次出现 | 建立初始意义 | 金锁 = 姐姐送的生日礼物（温暖） |
 | 第 2 次出现（中段转折） | 意义被颠覆 | 金锁 = 金包铜的假货（虚伪） |
 | 第 3 次出现（结尾） | 情感暴击 | 金锁被丢进垃圾桶（彻底决裂） |
 
 ### 物件设计模板
 
-填写以下模板，写入设定.md：
+采用贯穿道具时，按实际出现次数记录；长篇写入对应 `设定/` 文件，短篇写入 `设定.md`：
 
 ```
 物件：{名称}
-第1次出现：第{N}节 | {场景} | 含义：{初始意义}
-第2次出现：第{N}节 | {场景} | 含义：{转折意义}
-第3次出现：第{N}节 | {场景} | 含义：{结尾意义}
+| 章/节/场景 | 当次含义 | 新增信息或意义变化 |
+|---|---|---|
+| {位置} | {当次含义} | {首次建立/后续变化} |
 ```
 
-------|------|------|
+| 类型 | 功能 | 示例 |
+|------|------|------|
 | 信物型 | 承载关系的象征物 | 金锁（姐夫捎路）、木头小马（皇弟） |
 | 工具型 | 日常使用的功能性物件 | 打分本（准儿媳）、账本（迟来二十年） |
 | 痕迹型 | 残留的身体/环境痕迹 | 手腕旧疤、墙上身高刻度 |
@@ -147,16 +148,18 @@
 
 ### 规则
 
-前 100 字必须包含 ≥ 3 个事件。不做背景铺垫，直接上事件链。
+按题材和本章任务选用事件链开场，检查因果、有效变化和开头钩子，事件数随内容而定。
 
 ### 操作指令
 
-- 删除所有开头背景介绍（「在古代XX年间」「她是一个XX的女孩」）
-- 第 1 句就是事件，不是描述
-- 事件密度检查：数前 100 字里有几个独立的「发生的事」
+- 压缩无功能背景（「在古代XX年间」「她是一个XX的女孩」），保留理解当前处境所需的信息
+- 用行动、异常或具体处境建立阅读问题
+- 核对实际事件或信息变化是否推进目标、风险、关系或下一步行动
 
 ### 事件密度示例
 
+这组例子示范高密度事件链开场：
+
 ```
 ❌ 低密度（1 件事/100 字）：
 「沈栀是沈家的嫡女，自幼聪慧，深得父亲喜爱。这一天，她收到了一道圣旨。」
@@ -170,13 +173,11 @@
 
 ### 密度检查模板
 
-写完开头后，列出前 100 字的事件清单：
+写完所选事件链开头后，按实际内容逐项记录：
 
 ```
-事件1：{事件}
-事件2：{事件}
-事件3：{事件}
-（如果列出 < 3 个，重写开头）
+事件/变化：{实际内容}
+是否推进：{是/否；改变了什么}
 ```
 
 ---
@@ -251,8 +252,8 @@ IF 主事件是一连串动作 → 加「递进」：动作引发的连锁反应
 - 同一约束如果在「核心事件 / 内容概括 / 情节安排 / 情节点」里重复出现，生成前只合并成**一个语义点**；重复字段不是强调，更不是四次复述额度。正文不得沿用提纲里反复出现的同一措辞逐项交代。
 - 五段式（起因/发展/转折/高潮/结尾）是给细纲作者的功能拆解，不是正文的五个自然段；正文不必逐段顺叙，也不必一段对一格。
 - "谁做了什么"的概括句、"A→B→C"箭头链、"收束到什么状态"是规划口径，不要原样搬进叙述。
-- 同一场戏里的几个点可以合并、互相打断，不必排成逐点清单；因果依赖或刻意的停顿分隔才串行。只改顺序不会让正文变好看（交错与否的对照实验测不出差别），密点展开、疏点带过更要紧（见「疏密分配」）。
-- 章尾落在最后一个具体的动作、画面、台词或悬念上；细纲「结尾设定」是规划口径，不要在正文里写成"就这样……""他终于明白……"式的状态总结句（结尾去升华见 anti-ai-writing.md）。
+- 同一场戏里的几个点可以合并、互相打断，不必排成逐点清单；因果依赖或刻意的停顿分隔才串行。交错要有行动或信息关系，重点仍是密点展开、疏点带过（见「疏密分配」）。
+- 章尾落在最后一个具体的动作、画面、台词或悬念上；细纲「结尾设定」是规划口径，不要在正文里写成"就这样……""他终于明白……"式的状态总结句（结尾功能见 narrative-focus.md）。
 
 ### 视角姿态：深度限知（贴地沉浸）
 
@@ -261,9 +262,9 @@ IF 主事件是一连串动作 → 加「递进」：动作引发的连锁反应
 - **镜头不拉远、不俯瞰、不切他人内心**：别写"整个大厅陷入死寂"这种摄像机视角，写"她听见自己的心跳，旁边的呼吸声一下子全没了"。
 - **读者与角色同步获知**：角色不知道的不写；不提前剧透，不补全背景。悬念来自"她也不知道"，禁止提前剧透句如"她不知道的是"。
 - **念头是动作的一部分**：用半句的、被打断的、带情绪偏见的主观判断，不写完整理性的内心独白；不强配身体动作，情绪落地按第 1 节。
-- **主观偏差代替客观叙述**：场景被角色情绪染色。她恨谁，谁就被写得可憎；她慌，光线就晃。不写中立的、谁看都一样的描述。但只能是她此刻带偏见的瞬间感觉，不能写成"像在宣判一件早已定好的事"这类客观盖棺断言（那是作者下场定性，见 anti-ai-writing.md 模式 8）。
+- **主观偏差代替客观叙述**：场景被角色情绪染色。她恨谁，谁就被写得可憎；她慌，光线就晃。不写中立的、谁看都一样的描述。但只能是她此刻带偏见的瞬间感觉，不能写成"像在宣判一件早已定好的事"这类客观盖棺断言（叙述信息边界见 expression.md）。
 
-深度限知是"自然去 AI"的根：把镜头钉死在角色身体里，作者就没有位置跳出来解释、总结、安排了（配合 anti-ai-writing.md 模式 8）。
+采用深度限知时，把镜头留在角色当下的感知与判断中；解释、总结是否越界按文风与信息边界判断（见 expression.md），不把视角限制当成通用去味法。
 
 ### 文风指纹：按题材借 cadence，不套万能腔
 
@@ -439,4 +440,4 @@ IF 主事件是一连串动作 → 加「递进」：动作引发的连锁反应
 
 **标价发生在事情起效之前**，不能等结果出来再补。反面：该标价的人就在场，却只写他"笑了笑，凑到旁边说了句什么"——位置留了，内容没给。
 
-**尺子要先于被度量的事出场，至少两把**（同场另一个做到几寸、当年最好的那个用了多久）。事后补一轮尺子也可以（同一个爽点吃第二遍）。
+**首次建立分量时，先给至少两把可比较的尺子**（同场另一个做到几寸、当年最好的那个用了多久）。事后补一轮尺子也可以（同一个爽点吃第二遍）。

package/lib/oh-story/skills/story-setup/references/diagnostics.md

@@ -1,16 +1,16 @@
 # 仅检查写作环境
 
-用于 `story-setup check` 或「检查写作环境」「为什么 agent 不可用」等诊断请求。默认只读，完成报告后结束；不复制文件、修改配置、创建部署标记，也不运行部署、迁移或提交命令。用户已要求修复时，先列出发现，再按 `story-setup/SKILL.md` 的原有部署流程与对应宿主的 `references/deploy-*.md` 处理。
+用于 `story-setup check` 或「检查写作环境」「为什么 agent 不可用」等诊断请求。只检查并报告，不复制文件、修改配置、创建部署标记或运行部署、迁移、提交命令。用户已要求修复时，先列出发现，再按 `story-setup/SKILL.md` 的原有部署流程与对应宿主的 `references/deploy-*.md` 处理。
 
 ## 1. 确定检查对象
 
 优先使用用户指定的项目根；未指定时从当前目录向上找最近的 `.story-deployed`。找不到则报告「未找到部署标记，无法确认部署状态」，检查现有文件和运行环境，不据此自动初始化。不要扫描无关项目。
 
-读取 `.story-deployed` 的目标端、版本和 reference 路径。多个目标端分别检查；字段缺失、内容不可解析、目标端未知时记录具体问题，不猜一个端写回。部署版本与正在执行的 `story-setup/SKILL.md` 比较；本地包可能落后于项目，不把降级重铺当作修复。
+读取 `.story-deployed` 的目标端、版本和 reference 路径。多个目标端分别检查；字段缺失、内容不可解析、目标端未知时记录具体问题，不猜一个端写回。将 `agents_version` 与当前 `story-setup/SKILL.md` 比较；本地包较旧时先更新，不能降级重铺。
 
 ## 2. 复用部署验证
 
-以每个目标端对应的 `references/deploy-{target_cli}.md` 里的「部署清单」与「验证」为准（只读目标端那几份），加上 `story-setup/SKILL.md` Phase 3 的部署标记检查，逐项读取目标文件并执行只读校验。不要维护另一份 skill 名称、数量、agent 路径或 hooks 事件清单。
+以每个目标端对应的 `references/deploy-{target_cli}.md` 里的「部署清单」与「验证」为准（只读目标端那几份），加上 `story-setup/SKILL.md` Phase 3 的部署标记检查，逐项读取目标文件并执行只读校验。skill、agent 与 hooks 清单均沿用部署文件。
 
 - 区分安装的 skill 包和项目部署副本：Claude Code、Codex、OpenCode 的项目路径主要保存 agent、hooks 和参考资料，不要求在那里出现整套 `SKILL.md`。其他端按各自部署清单检查；skills-only 端没有原生 agents/hooks 是预期行为。
 - 参考资料按源目录的相对文件列表逐一核对，包含子目录；只看目录非空或文件数量相同不足以证明完整。源包不可用或源与目标是同一份时，说明无法独立验证完整性，不把它判为通过。
@@ -33,6 +33,6 @@
 
 ## 4. 报告与后续
 
-读者是不懂编程的作者。报告先用写书的话写两段：「现在能用什么」（正常可用的写作能力，一句话概括）和「需要你做什么」（逐条可照做，如「新开一个会话」「在 Codex 里打开 /hooks 信任一下」；没有就写「无需操作」），这两段不出现脚本名、字段名、状态名或文件路径。之后才按「发现的问题」「未验证项」汇总技术明细，每项给出目标端或书目、文件路径/命令结果、具体影响和下一步；正常结果合并概述，skills-only 的预期限制不渲染成安装失败。结论限定为本次实际检查的范围，不承诺所有写作能力都已验证。
+读者是不懂编程的作者。报告先用写书的话写两段：「现在能用什么」（正常可用的写作能力，一句话概括）和「需要你做什么」（逐条可照做，如「新开一个会话」「在 Codex 里打开 /hooks 信任一下」；没有就写「无需操作」），这两段不出现脚本名、字段名、状态名或文件路径。之后才按「发现的问题」「未验证项」汇总技术明细，每项给出目标端或书目、文件路径/命令结果、具体影响和下一步；正常结果合并概述，skills-only 的预期限制不渲染成安装失败。结论写明本次实际验证的能力。
 
 需要补部署文件时建议重跑 `story-setup`；源包本身缺失或比项目旧时先更新源包，再部署；当前会话未加载能力时提示新开会话或完成该 CLI 的信任步骤。仅检查请求到此结束，不为了消除告警自行执行修复。

package/lib/oh-story/skills/story-short-analyze/SKILL.md

@@ -8,8 +8,7 @@ metadata: {"openclaw":{"source":"https://github.com/zenstory-ai/oh-story-claudec
 
 你是短篇小说结构分析师。
 
-**核心：短篇靠共鸣和爆点驱动。拆文就是看它用什么故事核、怎么铺垫、在哪里引爆，把
-分析叙事写进 `拆文报告.md`，结构计数写进 `_meta.json`，下一篇短篇直接读这些写。**
+**围绕故事核，分析源文如何铺垫、释放情绪并引发共鸣。分析写进 `拆文报告.md`，结构计数写进 `_meta.json`，供下一篇短篇参考。**
 
 ---
 
@@ -23,7 +22,7 @@ metadata: {"openclaw":{"source":"https://github.com/zenstory-ai/oh-story-claudec
 
 ### Step 1：拿到原文
 
-问用户：**「你要拆哪篇？（标题+平台/来源）」**
+对象尚未明确时问用户：**「你要拆哪篇？（标题+平台/来源）」**；已有明确原文时直接继续。
 
 **无文本时**：用户没有提供原文文件路径、也没有在对话中贴出原文，引导用户提供
 ——「请提供这篇短篇的原文文件路径，或直接把原文贴给我。」
@@ -108,7 +107,6 @@ word_count = 全文字数
 3. 如果用户未提供源文件路径（直接在对话中贴文本），将原始文本保存到
    `拆文库/{书名}/原文/原文.md`
 4. 备份完成后验证 `原文/` 目录下文件非空（>0 bytes）
-5. 此步骤确保即使拆文过程中出现异常，原始材料不会丢失
 
 备份完成后初始化 `_meta.json`：写入 `version`、`word_count`、`genre_detected`、
 `created_at`、`stages_completed: []`、`last_stage_in_progress: null`。
@@ -119,8 +117,7 @@ word_count = 全文字数
 
 ### 5 阶段管道
 
-**预期耗时提示**：短篇拆文通常 10-30 分钟；同类对比或平台适配会更久。若文本很短，
-先只挑关键节点，不要为满足节点数量硬拆。
+原文较短时只提取实际变化，不为凑节点数量重复拆分。
 
 | 阶段 | 名称 | 输入 | 输出 | 完成标志 |
 |------|------|------|------|----------|
@@ -150,7 +147,7 @@ word_count = 全文字数
 
 ---
 
-## 验收（Stage 6 之后、写 stages_completed[6] 之前）
+## 验收（Stage 6 内容写完后、将 6 加入 stages_completed 前）
 
 Stage 6 内容写完后**不**立刻 append `6`，先按 output-contract.md「验收接入点」跑三道检查，全过才写：
 
@@ -180,7 +177,7 @@ Stage 6 内容写完后**不**立刻 append `6`，先按 output-contract.md「
 |---|---|---|
 | 准备开写 | story-short-write（同时读 拆文报告.md + 情节节点.md + 写作手法.md + 原文/ + _meta.json） | `/story-short-write` |
 | 需要市场数据 | story-short-scan | `/story-short-scan` |
-| 字数 > 20k 更适合长篇 | story-long-scan → story-long-analyze | `/story-long-scan` |
+| 字数 > 20k 更适合长篇 | story-long-analyze | `/story-long-analyze` |
 
 ---
 
@@ -215,10 +212,3 @@ Stage 6 内容写完后**不**立刻 append `6`，先按 output-contract.md「
 所有 references 在 `story-short-analyze` 中都是**观察标尺**——先报告源文实际发生了什么，
 再说明它接近、偏离或改造了哪种模式；不是按文件指引写新作品，也不从相邻长篇 Skill
 加载题材、节奏或质量资料。
-
----
-
-## 语言
-
-- 跟随用户的语言回复，用户用什么语言就用什么语言回复
-- 中文回复遵循《中文文案排版指北》