mcpField
N
novel-writing

novel-writing

github.com/wgwtest创意与媒体54107 次安装5 周前更新
代码仓库

关于 novel-writing

Novel Writing 是面向小说创作与评审的技能,涵盖规划、起草、续写和修订,并提供跨稿件版本与作者反馈的管理方法。它强调叙事因果、角色认知、场景行为和保留作者风格。

主要功能

  1. 01规划章节、场景与故事大纲
  2. 02起草、续写和改写小说
  3. 03检查结构与角色引入
  4. 04依据具体问题评审作品
  5. 05协调稿件版本与作者反馈
  6. 06保留作者风格和叙事细节

适用场景

  1. 01规划章节冲突与故事走向
  2. 02续写或改写已有小说章节
  3. 03检查场景中的信息与行动逻辑
  4. 04比较作者修改稿并整理反馈

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/wgwtest/novel-writing --skill novel-writing

安装后在 Claude Code 中输入/novel-writing确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

agents/
openai.yaml
references/
character-introductions.md
cognition-layers-and-language.md
dialogue-and-behavior.md
manuscript-lifecycle-and-feedback.md
planning.md
realism-constraints.md
revision-checklist.md
scene-and-structure.md
scene-causality-and-agency.md
story-outline-and-causal-summary.md
style-fidelity.md
scripts/
check_manuscript_text.py

详细介绍

小说创作

概述

当小说创作需要叙事技巧,而不只是润色句子时,请使用此技能。它涵盖规划、起草或续写正文,以及审阅已完成的小说。如果任务涉及不同章节版本,它还会协调项目的稿件交接,并吸收作者反馈中的经验。

使用时机

在用户要求以下事项时使用此技能:

  • 规划章节、场景、故事线、卷、全篇大纲、故事梗概、设定文档或揭示顺序
  • 搭建一个小说项目,以便在多个会话中保留正式章节、工作修订稿和作者反馈
  • 续写或改写小说正文
  • 检查章节在结构上是否扎实
  • 审阅角色是否介绍得清晰
  • 修订时保留作者原有的风格
  • 将作者手动编辑的章节与实际交付版本进行比较,并把有依据的反馈应用到后续创作中
  • 按照现有项目的稿件和存档规则交付修订稿
  • 检验场景是否遵守现实限制,例如可见度、程序、年龄或能力

以下请求请勿使用此技能:

  • 仅涉及诗歌的请求
  • 剧本格式相关工作
  • 无需叙事判断的纯文字校对
  • 非虚构写作

阶段选择

对于项目搭建或涉及多个稿件版本的工作,请按下文指示加载生命周期参考资料。对于正文任务,请判断任务所属阶段。

1. 规划

当用户在动笔前决定场景、章节、故事线、卷或全篇应起到什么作用时使用。

阅读:

  • 规划场景或章节时,阅读 references/planning.md
  • 规划故事线、卷或全篇大纲,撰写故事梗概,或编写独立的设定/理论文档时,阅读 references/story-outline-and-causal-summary.md
  • 当决策受知识、动机或信息披露影响时,阅读 references/cognition-layers-and-language.md
  • 当涉及冲突、责任、行动顺序或章节衔接时,阅读 references/scene-causality-and-agency.md
  • 当计划中的会面、访谈、咨询、调查或技术场景可能变成轮流陈述的说明时,阅读 references/dialogue-and-behavior.md
  • 当主要关注章节流畅度时,阅读 references/scene-and-structure.md
  • 当章节依赖现实限制时,阅读 references/realism-constraints.md
2. 起草或续写

当用户需要创作新的小说正文、改写正文或续写现有章节时使用。

阅读:

  • references/character-introductions.md
  • 当决策或对话取决于知识、判断或动机不对等时,阅读 references/cognition-layers-and-language.md
  • 当涉及冲突、行动、权威或连贯性时,阅读 references/scene-causality-and-agency.md
  • 当涉及持续对话、会面、访谈、审讯、家庭冲突,或实验室和研究场景时,阅读 references/dialogue-and-behavior.md
  • references/scene-and-structure.md
  • references/style-fidelity.md
  • 当场景依赖现实约束时,阅读 references/realism-constraints.md
3. 审阅

当用户希望对现有小说进行批评、诊断或获取修订建议时使用。

阅读:

  • references/revision-checklist.md
  • 当对话读起来像文字记录、角色依次发言,或场景中虽有动作却缺少人物回应时,阅读 references/dialogue-and-behavior.md
  • 然后加载与发现的问题相符的具体参考文件

长篇小说上下文策略

当小说项目篇幅已长到加载完整正式稿件并不划算时,请使用上下文 LOD,而非优先阅读全文。

加载顺序
  • L0 Task:当前要完成的写作或审阅任务

  • L1 Hard constraints:大纲、时间线、设定、问题记录、项目本地规则

  • L2 Near-field full text:当前章节、相邻章节,以及需要忠实还原时关联的稿件层

  • L3 Far-field structure:章节卡片、时间线片段和大纲片段

  • L4 Cold zone:无关的未来章节和较远处的全文,默认排除

  • 如果你要直接修订某个章节,请阅读该章节的全文。

  • 如果对话节奏、心理细节、模糊性、调情或身体细节描写很重要,请阅读相关全文,而不要依赖摘要材料。

  • 如果结构卡片与项目权威正文冲突,请标出差异,并以正文作为本任务的依据。只有在项目规则和当前授权允许时才更新卡片;未经审阅的作者修改不会自动成为正式设定。

  • 如果现有结构化上下文不足,请针对性地扩展全文阅读,不要加载整部小说。

  • 默认排除未来章节的正文,除非已确认的连续性依赖要求纳入。

稿件与作者反馈管理

创建小说项目或处理章节版本、手工编辑或带注释的作者草稿、交付内容或跨会话恢复时,请阅读 稿件生命周期与作者反馈。此技能用于协调当前稿件、工作修订稿、冻结证据和可复用作者反馈之间的设置或交接;这些内容的路径和权威性由项目自身规则决定。不要另建一套版本系统,也不要假设写作或审阅工具拥有项目的正式稿件。对于并行负责章节的情况,请遵循当前项目明确规定的工作流。

硬性规则

读者所知不等于作者所知

绝不要假设读者已经知道:

  • 某个角色是谁
  • 人物之间的关系
  • 某个地点是什么样子
  • 某种行为为何重要

如果作者知道,但正文尚未呈现,就应视为缺失。

重要角色不能毫无铺垫地登场

重要角色首次有效登场时,正文必须提供足够信息,让读者能初步认识他们:

  • 身份或角色
  • 与当前事件或视角的关系
  • 给人的第一印象

如果该角色是反派、恋爱对象、对手或核心盟友,正文还需要至少提供一个可辨识特征,例如:

  • 外貌
  • 衣着
  • 姿势
  • 声音
  • 习惯性动作
  • 他人的反应
场景信息必须遵守认知边界

角色只能知道场景条件允许他们知道的信息。

务必区分:

  • 他们能看到什么
  • 他们能听到什么
  • 他们能亲手触及什么
  • 他们能正确推断什么

看见某物不等于理解它。靠近过一次不等于有时间仔细查看。

认知必须影响选择与措辞

在作出重要决定或展开对话之前,先区分信息的分布与认知状态。追踪哪些信息是共享的、专业的或私有的;然后区分观察、转述、判断、意图和误认。

利用共同理解约束场景,避免重复说明;利用专业知识改变风险或可用方法;利用个体认知决定角色会选择、隐瞒、歪曲、试探或说出什么。所有这些都要结合当前角色、时间和受众来判定。

视角并不掌握所有决定

将体验中心、问题负责人、决策负责人、领域参与者和执行负责人区分开来。视角决定读者最先感受到什么压力;但它并不会自动赋予权力、专业知识或永久控制权。

让关键场景清晰呈现为感知或误解、选项收窄、决策、行动、后果和重新评估。将这条链视为诊断框架,而非强制公式,也不是禁止全知视角或多视角小说的规定。

对话必须通过行为展开

持续的对话必须扎根于具体情境并产生后果。角色只是摆弄道具或器械,并不能让场景自动变得活跃。要区分功能性动作(揭示策略或改变下一个节拍)与装饰性动作、程序性动作。

不要试图通过给每句台词加上情绪标签或随意的手势来修补像访谈记录一样的文字。动作密度不是质量指标,节拍也不必均匀分布。如果声音和压力都很清晰,快速对话可以不加标注。在信息落地、谎言受到检验、权力发生转移、克制失效或决定改变时,加入行为节拍。

因果与回应检查是作者侧的诊断工具,而非逐句叙述模板。让语境、对话、动作和停顿承载交流;直接写出沉默也完全有效。请参照对话与行为中的区分,而不要习惯性地解释某句话是否得到了回应。

每个场景段落都必须证明其价值

每一章或功能性段落都应能回答:

  • 这一段在处理什么问题?
  • 谁在这里发生了变化?
  • 到结尾时,什么向前推进了?

如果文字只是不断堆积内容,却没有改变局势,就应视为结构薄弱。

保护承载风格的内容

默认保留作者的:

  • 对话
  • 内心想法
  • 旁逸斜出的质感
  • 观察细节
  • 调情或暧昧
  • 承载节奏的重复

你可以修正措辞、标点、转录噪声和段落划分。不要悄悄把具体内容压缩成摘要。

审阅结果必须具体

审阅小说时,报告具体发现,并说明:

  • 位置
  • 问题类型
  • 为什么不成立
  • 如何修改

避免使用“有点生硬”或“可以改进”之类的模糊评论。

项目规则优先于本技能

如果小说项目已有本地规则、风格约定或手稿层级规则,应优先遵循。本技能提供通用的小说创作方法,不是项目专属的规定。

工作流程

  1. 确认任务属于项目设置、正文阶段,还是跨手稿版本或作者反馈的工作;在这些情况下,编辑项目文件夹或手稿文件前,先加载生命周期参考。
  2. 确定任务所需的最低上下文层级。
  3. 只加载该阶段所需的参考文件。
  4. 获取更多正文前,先加载项目本地的大纲、时间线、设定和问题文件。
  5. 修订语言、风格或章节连贯性时,获取附近的完整正文。
  6. 提出正文修改方案前,先应用硬性规则。
  7. 如果是审阅,先给出结构化发现,再提供摘要。
  8. 交付纯文本手稿文件时,运行随附检查器:python <skill-directory>/scripts/check_manuscript_text.py <file-or-directory>;检查警告,但不要将其自动视为正文缺陷。
  9. 如果任务涉及敏感的真实性约束,而你不确定,就说明哪些内容需要核实,不要虚张声势。

参考资料

评论

支持 Markdown