mcpbeat

���用 ���出纵横小说版

lornshrimp/通用-输出纵横小说版

用于把小说章节改写为更适合纵横小说网的版本。适合中等节奏、现实锚点扎实、慢热逻辑推进、人性落点显化与克制悬念渲染的正文输出;供多个题材的 `题材名-输出纵横小说版` 包装层路由使用。关键词:输出纵横小说版、纵横中文网、中等节奏改写、男频悬疑平台。

9k tokens
context cost
the whole folder, loaded on every use
3
files
instructions only
0
copies elsewhere
how many repositories repackaged it
148
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/lornshrimp/Lorn.NovelWriteSkills --skill 通用-输出纵横小说版

The instruction itself

3 sections, as written by the author

通用-输出纵横小说版

> 题材路由:若 .github\题材专用Skills\ 目录存在对应的 <题材>-输出纵横小说版 Skill,则:

> - 将题材特性骨架路由到 <题材>-输出纵横小说版,该 Skill 位于 .github\题材专用Skills\ 目录。

> - 命中本技能时,必须优先强制加载当前 Skill 与 <题材>-输出纵横小说版。

这是平台共性本体,负责承接"纵横小说版输出"的跨题材共性规则。

<!-- ===== Layer 1: 永久缓存 ===== -->

常见触发词 / 用户说法速查

  • 输出纵横小说版
  • 改成纵横能发的版本
  • 做纵横平台改写
  • 帮我把这章改得更适合纵横的中等节奏
  • 纵横化改写

<!-- ===== Layer 3: 场景缓存 ===== -->

何时使用

  • 把任意题材章节改写成更适合纵横小说网读者的版本。
  • 需要强化中等节奏、克制悬念、现实锚点与人性落点。
  • 需要为题材包装层提供统一的纵横平台共性骨架。

不适用情形

  • 只做题材边界补充,不做平台输出本体。
  • 只做多平台编排、落盘和终检,而不处理纵横平台风格本身。

本层职责

  • 维护纵横平台的跨题材共性规则。
  • 统一承接纵横版输出的标题倾向、结构约束、字数与风格门禁。
  • 调用 通用-设计标题 的嵌入式轻量模式对本章标题做平台适配优化,确保标题长度不超过本平台截断风险线、标题风格符合本平台读者预期。
  • 题材名-输出纵横小说版 提供稳定的通用平台骨架。

平台默认字数范围

以下为本平台通用默认字数范围,适用于未在项目 Agents.md 中指定字数覆盖值的情况。若项目 Agents.md 已指定该平台的字数要求,则以 Agents.md 为准。

  • 正文:3000–5000 CJK
  • 作者有话说:200–300 CJK

参考文件

  • references/平台共性执行细则.md
  • references/分节级补救映射与详细规则回填.md

与题材包装层的协作说明

  • 若对应题材已有 题材名-输出纵横小说版,必须先由题材包装层锁定:题材边界、题材禁行项、题材专项补丁、题材 refs 调度与题材输出口径。
  • 本 Skill 只负责纵横平台的跨题材共性:标题倾向、中等节奏、克制悬念、现实锚点、人性落点、平台门禁、落盘与终检骨架。
  • 若题材包装层与本 Skill 出现冲突:
  • 题材边界、题材禁行项、题材专项补丁 → 以题材包装层为准;
  • 平台共性节奏、平台结构、平台终检门禁 → 以本 Skill 为准。
  • 若用户直接命中本 Skill 且仓库内存在对应题材包装层,不应绕过题材包装层直接把平台共性套到正文上。
  • 若仓库内暂时不存在对应题材包装层,本 Skill 只能保守执行平台共性,不得臆造题材规则。

缓存优化说明

本 Skill 的结构遵循前缀缓存优化原则,调用时:

  • 缓存层 1(永久不变):frontmatter + 本层职责 + 平台硬规则 + 禁行项 + POV 契约 → 每次调用完全相同,LLM API 的前缀缓存永久命中,按底价计费
  • 缓存层 2(同平台内不变):平台模板自动发现规则 + references 清单 + 默认执行顺序 → 仅在切换平台或新增模板注册时变化
  • 可变层(每次变化,不写入本文件):本次目标章节号、源稿路径、用户指定的特殊平台约束 → 由用户每次调用时指定,按正常输入价计费

人物传记、故事设定、写作研究模板等 references 通过 ## 继续读取的 references 声明强制加载,其固定部分随本 Skill 一起进入缓存前缀。

<!-- ===== Layer 2: 项目级缓存 ===== -->

平台模板自动发现规则

若当前服务的项目根目录存在 Agents.md,执行纵横版输出前必须:

  • 读取项目根目录的 Agents.md
  • Agents.md 中注册了三类模板,按以下优先级检索:
  • 优先:模板注册时 "适用平台" 字段为 纵横 的同类型模板
  • 回退:模板注册时 "适用平台" 字段为 默认 的同类型模板
  • 忽略:模板注册时 "适用平台" 指向其他平台的模板(如 番茄起点),本轮不加载
  • 若检索到匹配的三类模板——读取对应路径的模板文件:
  • 写作研究模板:作为纵横平台的额外平台基线约束
  • 作者风格模板:作为纵横版本保留底味和文风边界的参照
  • 作品蓝本模板:作为章首/回报/钩子结构保真的参照
  • 若项目根目录不存在 Agents.md,或其中未注册纵横专属模板——回退通用默认模式,不影响正常输出
  • 本 Skill 的核心约束始终是:平台规则 > 安全合规 > 母稿事实 > 三模板约束。三模板是辅助,不改变平台输出规则

默认执行顺序

  • 先锁定源稿不可变层:事实、事件链、证据链、角色关系与因果顺序不得改坏。
  • 读取对应题材的 题材名-输出纵横小说版 Skill,确认题材入口与路由关系。
  • 再读取本 Skill 的 references/平台共性执行细则.mdreferences/分节级补救映射与详细规则回填.md,执行纵横平台的中等节奏调整、克制悬念渲染、现实锚点强化与人性落点显化。
  • 由题材包装层继续读取其题材 references,锁定题材边界、题材禁行项与题材专项补丁(作为兜底约束)。
  • 在“平台优先、题材兜底”前提下执行改写正文,确保平台化表达与源稿保真同时成立。
  • 最后才处理降相似度,不得为了降重破坏中速节奏、现实锚点与人性落点。
  • 执行 POV 契约复核,确保与 platformPovContract 一致,不得出现未授权人称漂移。
  • 改写输出完成后,必须立即执行“输出后自检与修订”节的五项自检,不得跳过。
  • 若自检未通过,必须按结论回炉修订并复检,直至“自检通过/自检修订完成”后方可落盘。

POV 契约与连续性(强制)

  • 若本次由 通用-多平台输出编排 调度,必须继承该流程已锁定的 platformPovContract,不得在本 Skill 内重新决定人称。
  • 若用户直接命中本 Skill,则必须在改写前先从源稿正文与当前平台已完成前序章节中推断并锁定 platformPovContract;默认优先级为:用户明确指定 > 当前平台已完成前序章节 > 源稿既有 POV 链路 > 本批次首个已通过章节。
  • 未获批准不得把连续章节从第三人称静默改成第一人称,或反向漂移;若源章本来就是视角切换章 / 多视角连续章,只能按已登记 switchPlan 执行,不得临场换壳。
  • 落盘前后都必须显式执行 POV 校验,并把结果写入日志或执行记录;中文平台默认使用 scripts/pov_validate.pyscripts/run_pov_gate.ps1lang=zhauto 复核正文区块,第三人称链路检查对话外第一 / 第二人称,第一人称链路检查对话外第一人称锚点。

POV 选择指南(如无显式契约)

> 强制前置步骤:必须首先读取工作区根目录 Agents.md## 平台POV基线表 节,查找本平台的当前锁定人称。若基线表中无本平台条目,必须先在该表中创建条目并锁定人称(参考下方"适用场景分析"),再继续执行。

>

> 人称是全书级契约:基线表锁定值即为本平台全书的唯一人称,不得逐章切换,不得章内混用(对话引用除外)。极特殊情况下某章须切换主视角人物时,该章开头必须明确声明「我是[角色名]」,且整章只保持该角色的第一人称叙事。

若本次执行未获得上游明确的 platformPovContract 锁定,按以下指南为本平台适配稿确定人称(最终以 Agents.md## 平台POV基线表 节锁定值为准):

纵横小说版的人称适用场景(供创建/修订基线表条目时参考)

平台底层逻辑:纵横是"中等节奏 + 现实锚点"的男频悬疑主场。读者以成熟男性为主,核心需求是"与主角同步感知/推理的沉浸感"——他们不是来看热闹的,是来"一起破案"的。研究明确:"爆款作品几乎清一色采用限制性叙事视角……首选第一人称或限制性第三人称,严格锁定主角感知边界;禁止随意突破视角限制。全知视角是大忌——破坏推理参与感和现实可信度。"

为什么纵横两种人称都可行?

  • 纵横读者对"同步推理"的需求高于一切。无论是第一人称还是第三人称,关键约束是感知边界不可突破——读者获取的信息必须=主角获取的信息。上帝视角是唯一死刑。
  • 第一人称(如《捞尸人》):直接将读者锚定在主角的感官与认知中。"我摸出招魂结,绳结是红色的,上面沾着黄河泥"——读者与"我"完全同步,我怀疑谁读者就怀疑谁。沉浸式推理体验最大化。但在主角失去意识/被攻击/无法感知的场景中,信息传递受限。
  • 限制性第三人称(如《道爷不好惹》):既保留代入感,又比第一人称有更大叙事自由度。可以在必要时刻短暂切换到其他角色视角展现同一事件的不同侧面。所有描写必须有主角感知锚点:不写"房间有血腥味",写"他闻到一股血腥味"。

判断标准——回答两个问题

  • "主角有没有'失去意识/无法感知'的关键场景?"——如果有,第三人称给了你补信息的合法通道。
  • "故事最大的悬念,是让读者解谜,还是让读者共情?"——前者偏第三人称(信息拼图需要多视角),后者偏第一人称(恐惧和判断的即时传递最有力)。

章节题图与配图提示词(每章必出)

每章平台稿落盘时,必须在文件末尾(## 作者有话说## 章节后记 之后)追加"章节题图与配图提示词"区块,为本章提供可直接投喂 AI 生图模型的提示词。本节只输出提示词文本,不输出图片本身。

输出结构

文件末尾按以下顺序组织:

  • 题图提示词(章首图 / 章题图):1 条,用于本章章节卡与平台章首展示;从本章高光画面或核心意象中选取。
  • 配图提示词(正文插图):每章 0–2 张(默认 1 张;本章无可视化高光画面时不配,宁缺毋滥);每张必须同时给出插入位置与生图提示词。

配图插入位置规则(强制)

  • 每张配图的位置说明格式:插在第 N 段末(段首句:"……")——先写段落序号,再用该段开头 8–15 个字二次定位,确保无歧义。
  • 配图一律插在段落结束之后(段与段之间),禁止插在段落中间,禁止为插图拆段或改写段落。
  • 禁止写成"文中适当位置""高潮附近"等模糊描述。

正文零污染(强制)

  • 正文中不得插入任何图片占位符、[插图](此处配图)、HTML 注释等锚点或标记;平台稿正文保持纯文本。
  • 配图位置信息只写在文件末尾的配图提示词区块中;不插配图时,正文可直接整段复制上传,不受任何影响。

提示词质量要求

  • 题图与配图提示词必须是完整、可直接复制的 AI 生图提示词(含主体、环境、光线、构图、色调、风格与负面词),不得写成抽象描述或写作建议。
  • 提示词必须与本章内容强相关,禁止通用化套图;同一批多章之间不得复用同一套提示词。

默认输出口径

  • 默认输出一版可直接继续落盘或进入平台终检的纵横派生正文。
  • 默认保留原章核心事件链、中等节奏逻辑推进与章末悬而未决钩子,不新增关键事实。
  • 保住原章现实锚点、案件 / 事件逻辑链、人物代价与人性落点。
  • 读起来不像快节奏爽文稿,也不像把正文拖成氛围堆砌的慢热水文。

输出后自检与修订(必做,不得跳过)

改写输出完成后,必须立即执行本节自检;根据发现的问题就地修订,确认通过后方可落盘。不得以任何理由跳过本步骤。

五项自检:

  • 字数达标:正文和 ## 作者有话说 必须先满足本 Skill 的"平台默认字数范围"(或项目 Agents.md 中的覆盖值);
  • 正文目标以"平台默认字数范围"为准,即 3000–5000 CJK
  • ## 作者有话说 以"平台默认字数范围"为准,即 200–300 CJK
  • 正文未达推荐下限前,建议先回炉补足字数。
  • 严格禁止为凑字数进行模板化补字或机械扩写;如检测到模板句污染、解释腔堆砌或无意义重复,则判定字数虽足但自检失败,必须重写。
  • 零新增事实:改写版未引入源稿中不存在的关键事实、人物或设定;引入则删除/还原。
  • 核心事件链完整:起因→推进→高潮→章末钩子方向均在改写版中体现;断裂则补回。
  • 平台风格达标:改写版满足本 Skill“最低交付”(或平台核心风格要求)所列各项;不足则就地修订。
  • 无模板句污染:未出现连续 2 句及以上解释腔/模板腔/口径名词句群;命中则整段回炉。
  • POV 一致:改写版 POV 与已锁定的 platformPovContract 一致;漂移则回炉修正。

结论格式(必须输出):

  • 全部达标:[自检通过] 五项均达标,可落盘。
  • 已修订达标:[自检修订完成] 已修订:<问题描述>,现五项均达标,可落盘。
  • 未通过(不得落盘):[自检未通过] 命中:<问题描述>,需继续处理。

命中“未通过”后必须修订并重新输出自检结论,循环直至输出“通过”或“修订完成”方可落盘。

硬规则

  • 章节标题字数统计必须按纯标题口径执行:先去除开头 x.y.z 形式的章节编号及其紧跟空格,再仅对剩余标题正文计数。
  • 纵横平台章节标题纯标题长度不得超过 20 个字;但限制字数不代表追求“越短越好”,应先贴合纵横的平台表达风格与信息完整度,在不超限前提下可适当拉满可读信息。
  • 绝对禁止输出"抽象自述 + 动词模板 + 口径名词"的垃圾句群;凡出现类似"对照项落在… / 先把同一句话拆碎 / 先把顺滑的解释拆开 / 只求能追溯(复核、对得上)"等模板化短语,必须判定为污染并整稿回炉。
  • 严禁使用或间接调用以下脚本对正文做生成、扩写、拼接或降重:scripts/append_cn_unique_monologue.ps1scripts/append_cn_unique_narration.ps1scripts/append_cn_unique_thirdperson.ps1scripts/rephrase_cn_body.ps1scripts/rephrase_en_body.ps1scripts/cn_lexicon_profile_transform.ps1。这些工具不得进入平台正文生产链路。
  • 平台稿新增"模板句污染清零门禁":正文不得出现连续 2 句及以上"我/我这边/我心里… + 把/将… + 对齐/校准/锁死/拆开… + 连接词 + 口径名词 + 只求/不求/先把…"结构;命中即失败,不论字数与相似度是否通过。
  • 平台连续章必须服从已锁定的 platformPovContract;不得在本 Skill 内擅自把前序稳定链路改成人称新链路。
  • 若命中未授权 POV 切换或 POV 校验失败,必须按 pov_drift_detected / pov_switch_without_approval 判定失败并整稿回炉。
  • 命中本技能时,必须同时加载对应题材的 题材名-输出纵横小说版 Skill(若存在)。
  • 题材特有规则不得回写到本文件中平行维护。
  • 修改纵横平台共性规则时,应优先修改本 Skill,而不是多个题材入口。
  • 平台派生正文默认落在本 Skill 的工作目录 纵横小说/ 下。
  • 章节级派生正文目录统一按小说结构决定:若作品有分部,则位于 纵横小说/第X部/第Y卷/;若作品无分部,则位于 纵横小说/第X卷/
  • 平台派生正文文件名默认不带日期,沿用既有章节号与平台标题同步规则;日期只用于配套审阅报告、书评等派生产物。
  • 章节派生正文必须以 .md 文件形式落盘:若对应章节目录不存在,执行前必须先创建完整目录路径,再将改写后的章节内容写入该目录下的 .md 文件,不得只输出聊天稿而不写入文件。
  • 落盘路径的完整推断优先级:① 用户显式指定 chapterPath → ② 从源文件名与分部/卷信息自动推断 → ③ 若无法确定分部/卷,暂停并向用户确认,不得乱推断后静默落盘。
  • 平台稿落盘后必须显式运行字数门禁:正文字数检测必须使用 scripts/count-chapter.ps1,不得用 LenNoWhitespaceLen、编辑器字符数或目测代替。字数参数以本 Skill 的"平台默认字数范围"或项目 Agents.md 覆盖值为准,用 scripts/count-chapter.ps1 校验正文;正文门禁只看 BodyCJK / MeetsMinCJK / WithinRangeMeetsMinCJK 必须为 TrueWithinRange 最好为 True## 作者有话说scripts/count-afterword.ps1 单独校验。
  • 生成阶段建议先达到字数目标再允许落盘:以本 Skill 的"平台默认字数范围"或项目 Agents.md 覆盖值为准。

与其他 Skill / Prompt 的边界

  • 本 Skill 只负责纵横平台的跨题材共性骨架。
  • 题材边界、题材禁行项与题材特有口径,继续由对应 题材名-输出纵横小说版 承接。
  • 题材 Prompt 只应路由到 题材名-输出纵横小说版;不应直接把本 Skill 与题材 refs 并列成双入口。

How to use it

Copy the folder

Take lornshrimp/通用-输出纵横小说版 from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.