tavern-card-builder

Tavern Card Builder

共享沟通规范

遵循 TW plain-language and guidance rules：首次使用术语时解释其含义，保持用户选择的新人／入门／熟练／老手级别，并在每个级别都说明必要的更改和 bug。灵魂模式和文风模式都不会停用这项基本要求。

插件运行环境

当此 Skill 通过插件、云主机或远程机器运行时，在开始时阅读 the plugin execution contract，并在执行针对特定主机的命令前，检查主机、工具和持久化相关事项。遵守此 Skill 的范围、授权和验收门槛。

确定卡片要呈现什么，以及各个部分如何协同工作。将这些创作决策保留在此处；工程工作交给相应的专家。

此创作约定有三种主要类型：text、mvu_zod 和 hybrid。 每张完成的卡片都需要有可用的开场白和世界书。新卡通常应将传统的描述、性格、场景、对话示例、系统提示词和历史后指令字段留空；主要内容应放在世界书中。这些是 TW 的创作选择，并不代表 SillyTavern 已移除这些字段。修改继承而来的卡片前，应先检查这些字段原有的用途。类型、组件和旧版 MVU 规则见 card-types-and-runtime-dependencies.md。

在设计任何可写入内容之前，使用 $consult-tavernweave-library 并选择 tavern-card-builder 路由，确保 A0 和最少量的匹配 ST 指南确实已阅读。将路由回执与项目权威资料一同保存；仅随附但未经路由和阅读的数据库不能作为证据。

随附的 ST 指南是有日期的技术快照。对于已采用的创作约定，请使用此 Skill 的当前参考资料；不要将快照中的无条件 Zod 提供方、注册包装器、固定深度／顺序或强制运行时配方套用到其他目标。报告矛盾，并通过 $sillytavern-api-reference 核实实际 API／版本。保留用户的明确决定和继承卡片的授权范围；不要改写历史指南来让它看起来像是当前指南。

对于新卡或长期维护的卡片，在撰写大量正文前，先按照 creative-authority.md 建立可续接的创作权威资料。对于源小说、笔记、聊天记录或研究资料，按照 material-provenance.md 补充来源链。对于持久化知识、状态、叙事回忆或创作者档案相关需求，按照 memory-architecture.md 将四类存储分开。

从目标开始

对于“接手一张卡／二创／继续更新别人留下的卡”，从 retrofit-and-text-cards.md 中的继承卡片流程开始。先说明卡片的实际内容，再提出更改；区分续写与衍生作品，保留用户选择的核心要素，并规划一项首次修改和一次后续迭代。PNG／JSON 导出文件不能证明存在受维护的创作源文件。继续沿用已确认的现有决定，不要重新讨论这些决定。

1. 阅读仓库说明，并在提出设计方案前检查现有卡片。
2. 当行为取决于具体实现或版本时，确认目标 SillyTavern、Tavern Helper、提示词模板和 MVU 的实现或版本。
3. 分别记录卡片和维护中的源文件所用的主类型，以及实际检测到的功能。旧版 mvu 标签不能证明支持 Zod，也不代表获准迁移。在决定用户必须安装什么、卡片必须内嵌什么以及哪些内容从远程加载之前，先建立运行时依赖清单。阅读 card-types-and-runtime-dependencies.md。
4. 设计新的世界书前，先请玩家选择小型、中型或大型，并说明接下来相应要做的工作。复用已明确确认的选择。阅读 worldbook scope and size；范围较窄的修复或只读审查，无需重新进行完整设计访谈。
5. 独立判断卡片是否需要自定义 CoT、预设中是否已有可复用的主 CoT、需要添加哪些卡片专属内容，以及哪些模块应按条件激活。不要根据卡片是否使用 MVU 来决定这些事项。
6. 对于 MVU 状态，确认更新是与剧情生成共用一轮，还是额外调用一次更新模型。对于运行时支持条目路由的新建 MVU Zod 卡，优先采用双兼容布局；除非明确获准迁移，否则保留现有卡片的当前模式。
7. 将尚未解决且与版本相关的说法记录为假设，并设置真实运行时验收关卡。

完整的创作流程请阅读 authoring-workflow.md。

处理角色时，只加载相关参考资料：角色设计用于创建或整理可扮演的素材；玩家资料与自主权用于处理玩家事实与限定范围的授权；角色阶段用于处理由状态选择的差异；角色呈现审查与修正用于诊断不理想的角色呈现或澄清具体误读。这些是不同职责，并非五个必填条目或新卡片类型。只有在确有帮助时才使用可选工作表，并链接现有的创作权威、变量契约和验收记录。根据请求的编辑、协作构思或委托创作范围开展工作。不要对每个角色都强加四段式档案、固定性格维度、三面系统、阶段引擎或修正条目。保留有效的继承结构。玩家事实不构成冒充玩家的授权；阶段读取器和角色呈现修正不得写入状态。运行时症状仍由运行时专家负责。

对于简短的、仅限聊天的角色、文案或角色卡规则请求，请检查相关的已提供材料，并仅交付所请求的草稿、说明或诊断，以及适用的决策和限制。对于不涉及重新设计这些部分的范围较窄的任务，不要要求提供整张卡片的清单、运行时版本、世界书规模访谈或所有交接字段。现有的事实、玩家自主权和授权边界仍然适用。

对于独立的角色卡提示词规则或创作限制，请加载独立作者规则。在内部使用其中的六项语义检查；保留作者要求的力度和已确认的例外。对于仅限聊天的请求，只交付所要求的规则正文。只有在创作实际世界书条目时，才同时提供正文和配置。这条路径不会把普通的文章写作请求或现实世界规则说明变成卡片工作；精确的 API 和运行时任务仍由各自的专家负责。 如需独立规划世界书、撰写正文、配置或进行只读审查，请使用 worldbook-design-and-writing。该文档负责场景／加载选项、条目边界、知识／文案约定及配套配置。完整卡片的 Content 地图和最终交付仍由本文档负责。创建世界请参阅 worldbuilding-design.md，核心角色激活、模型路由和 CoT 拼接请参阅 lorebook-and-prompts.md。局部编辑须保留稳定 ID、未知字段和无关设置。混合世界书不会重新定义卡片运行时类型。

如需了解开场风格和初稿，请阅读 opening-strategies.md。如需撰写卡片内的小型场景、剧情事件、物品或关系片段，请按要求的范围使用 card-writing.md。受委派的创作工作允许主动提出方案并落实常规创作选择；不要把它变成让作者填写的表单。已完成的文案应使用 自然中文审查进行作者质量检查。这不会启用持续改写模式。

如需评估面向作者的卡片或世界书，请先阅读 validation.md 中关于范围／状态和报告的章节，再选择相关专项检查。区分缺少必需内容与未提供审查的材料。除非任务同时授权修改，否则审查应保持只读。

撰写正文前先建立约定

对于每个系统，请记录：

• 其事实来源；
• 字段和默认值；
• 编写者、读取者、渲染器和清理责任方；
• 初始化和迁移行为；
• 模型可见的指令；
• 运行时依赖类别、交付方式、启用策略和失败行为；
• 验证证据。

对于自定义 CoT，追踪：

main CoT phases -> card increments -> conditional modules -> recipient model
                -> assembled prompt -> output boundary -> fallback -> acceptance

在创作源文件中使用稳定的阶段和规则 ID。既按含义去重，也按 ID 去重。卡片增补应添加卡片专属条件、例外或更严格的约束，而不是复制预设的完整 CoT。

对于 MVU 状态，通过以下链路追踪每个字段：

schema -> initialization -> update rules -> model projection -> runtime reader
       -> renderer -> write-back -> cleanup/migration -> examples/tests

不要添加没有使用方或生命周期的字段。编写 schema、更新规则或 MVU 模型路由前缀之前，请阅读 variable-systems.md。

选择开场策略

不要把所有开场都当作同一种协议：

• 对于固定首条消息或备用问候语分支，使用共享初始化加逐问候语初始化。
• 对于必须触发常规剧情／更新链的自由形式或多步骤设置，使用真实的用户开场消息。
• 切勿仅为让开场看起来已完成初始化，就使用辅助脚本冒充 MVU 初始化事件。

添加或移除 <initvar>、<UpdateVariable> 或开场向导行为之前，请阅读 opening-strategies.md。

分离创作层

即使一张卡片将这些层打包在一起，也要保持各层彼此独立：

• 卡片身份与叙述文本；
• 自定义 CoT 和卡片专属的 CoT 增量；
• 世界书与提示词路由；
• 持久化变量协议；
• 正则表达式转换；
• 运行时脚本与 API；
• 嵌入式 UI；
• 模块化源库；
• 构建与发布产物。

任务跨越创作边界时，请使用相应的技能：

• $sillytavern-card-components 用于安全拆分、注册表／配方工作和源文件往返；
• $sillytavern-card-pipeline 用于组装、验证、JSON／PNG 打包和发布门禁；
• $sillytavern-api-reference 用于查阅准确的签名、事件、宏和与版本相关的运行时事实；
• $sillytavern-runtime-debug 用于获取真实 SillyTavern 会话中的证据；
• $sillytavern-embedded-ui 用于消息内容页、开场页、状态栏、控制中心和对话框；
• $rolecard-workshop-ops 用于发布基础设施。
• $rewrite-natural-prose 用于按要求润色文本或使用已启用的改写模式；在该模式下润色创作交接内容，同时保留设定正典和受保护的技术字段。普通卡片创建不会启用或保留改写偏好。
• $code-quality-workflow 用于对卡片组织及其软件连接进行明确的全面／架构审查；创作改动须遵循现有门禁。

编写最精简且完整的设计

只阅读任务所需的参考资料：

• card-writing.md，了解身份字段、文本、问候语、示例和情节指导。
• cot-design-and-authoring.md，了解独立自定义 CoT 的定义、部署、模块化创作、预设／卡片拼接、模型路由、模板、预算、脚本边界和验收。
• worldbook-design-and-writing，了解独立条目规划、原生／模板选择、正文及配对配置。
• lorebook-and-prompts.md，了解核心角色激活、模型路由和 CoT 拼接。
• worldbuilding-design.md，了解可游玩的世界构建、因果关系、资源及其与状态／开场的关联；仅适用于世界书的方法链接到其归属文档。
• variable-systems.md，了解架构、初始化、更新、投影、清理和迁移。
• opening-strategies.md，了解固定问候语和动态设置流程。
• card-types-and-runtime-dependencies.md，了解类型检测、依赖类别、区域加载器和用户通知。
• regex-and-runtime-requirements.md，了解转换和脚本要求，避免臆造 API。
• retrofit-and-text-cards.md，了解如何保留现有卡片，或完全避免使用 MVU。
• 交接前阅读 validation.md。

稳定规则

• 将源文件与生成的产物分开。先修复源文件，再重新构建产物。
• 除非有证据且获得授权进行迁移，否则保留现有卡片经过验证的协议。
• 将命令方言和运行时行为视为与版本相关的能力，而不是普遍适用的经验法则。
• 根据卡片的架构、注册路径和打包的加载器脚本检测 MVU Zod，切勿仅凭 API 标识符判断。分别追踪内嵌架构、内嵌的国内版／全球版 MVU Zod 脚本、它们的 Git／CDN 目标，以及所需的宿主扩展。如果卡片已附带加载器脚本，则不要添加独立的 Zod 安装步骤。
• 不要悄悄安装扩展或远程运行时。分别报告内嵌、宿主、远程、区域性、可选和仅供开发使用的依赖项。
• 模型可见文本中不要包含事件历史、开发说明、对模型没有用途的 Markdown 装饰，以及可复制的硬编码输出。
• 将自定义 CoT 视为作者编写的决策协议，而不是访问模型隐藏内部推理的方式。应验证可观察到的行为和路由，而不是要求完整输出推理过程。
• 默认采用预设的主 CoT，加上卡片特定的增量和条件模块。按职责分开处理情节模型 CoT、更新模型提示词和确定性脚本计算。
• 对多语言或多行正文使用 UTF-8 安全且带保护的写入方式。变更前后均验证结构匹配情况。
• 优先采用项目中已验证的结构，而不是引入新的抽象。
• 按影响程度进行验证。影响运行时的变更，只有在真实的 SillyTavern 中获认可后才算完成。
• 不要仅仅因为创作计划已完成，就打包、发布、部署或覆盖用户的卡片。

交接格式

对于整张卡片或系统级工作，请返回下列适用项目。简短的角色草稿或范围有限的诊断，应采用上文所述的范围限定交付方式，而不是八项完整报告。

1. 目标卡片类型、检测到的能力及其依据；
2. 已达成共识的系统与排除项；
3. 运行时依赖清单，以及面向用户的安装／内嵌／远程加载说明；
4. 字段／知识库／组件契约，以及 CoT 部署／拼接契约；
5. 要创建或修改的文件或卡片章节；
6. 下一步所需的专业技能；
7. 已取得的验证证据；
8. 仍需进行的真实运行时验证或用户验收。