independent-narrative-app

ST-Compatible Independent RP App Builder

Version: 0.3.1
Author: 牢凌

把用户的想法逐步变成可运行、可维护、可验证的独立 RP 应用。SKILL.md 只做总控；进入具体阶段前读取最少必要的 references/*.md，不要一次加载整个知识库。

30 秒使用总览

适用任务

• 从零创建独立前端形式的 RP 角色卡应用。
• 把普通或 SillyTavern 角色卡、世界书、预设和相关资产迁移为独立应用。
• 审计或改造已有独立叙事应用的内容、运行时、状态、存档、Prompt、UI 和跨系统联动。
• 在已有 RP 应用中设计或实现角色、世界书、玩法系统、视觉风格、正文渲染和平台能力。

不适用任务

• 与 RP、角色卡或叙事应用无关的通用 React/Vue 页面、SaaS、后台管理和普通前端产品开发。
• 只制作 SillyTavern 内部角色卡、MVU 插件或酒馆脚本，且没有迁移为独立应用的目标。
• 与独立 RP 应用无关的纯小说写作、图片生成或一般桌面工具开发。

最少输入

用户只需提供一个可用入口：从零时给出作品想法；Card-to-App 时提供源卡或资产；改造已有应用时提供项目和问题；局部任务时说明现有作品背景与目标。平台、技术栈和详细系统可以暂未确定，由讨论逐步收敛。

主要输出

• 讨论阶段：作品草案、决定记录、暂定项和待验证项。
• 设计阶段：完整设计、系统设计卡、兼容报告和阶段路线图。
• 实施阶段：项目专用实施计划、代码、测试和可运行或可验证切片。
• 验收阶段：证据、通过/失败/未验证项、风险、迁移和回滚入口。

启动规则

先判断入口与风险，再建立 Task Envelope。资料不足时先讨论并提供方案；方向确认只允许进入完整设计，设计确认才允许实施。局部明确任务可以走轻量确认门，但不得跳过玩家主权、状态一致性、数据安全、来源保留和验证诚实性。

1. 核心边界

• 交付物是独立应用，不是必须依附 SillyTavern 的角色卡、插件或网页。
• 允许复用 ST World Info、Prompt/Preset、角色字段和宏语义作为外部兼容契约，但由独立运行时原生执行。
• 同时支持从零创建、Card-to-App、已有独立应用改造和局部内容/系统任务。
• 作品形态可以是陪伴、恋爱、冒险、群像、策略、RPG、沙盒、经营、长期生成式循环或混合形态；不要用封闭类型清单限制作者。
• 主目标始终是角色卡式 RP 游戏。地图、手机、记忆、相册等只是可替换示例，不是默认功能。
• 创作知识提供方案、影响和推荐；只有玩家主权、状态一致性、数据安全、来源保留和验证诚实性使用强制门槛。

2. 全局执行铁律（最高优先级）

铁律 0–12 高于所有 references/*.md、模板和阶段建议。分册只能细化铁律，不能覆盖、绕过或把“必须”降级为建议。先判断任务类型与风险，再选择适用门槛；不要把十三条机械地变成一次性问卷。

判断任务类型与风险
→ 选择完整确认门或轻量确认门
→ 建立或读取 Task Envelope 与讨论文档
→ 先确认作品与玩家体验，再确认结构与可行性
→ 设计系统、字段、状态和兼容边界
→ 按阶段交付并登记问题
→ 用匹配的验证维度提供证据
→ 版本化、备份、回滚并交付

铁律 0：先问清再动工

“问清楚”以阻塞决定闭合为准，不以提问轮数为准。

• 完整确认门：新应用、Card-to-App、新系统、重大玩法、核心契约或跨域行为变化，必须依次完成 理解想法 → 完善作品轮廓 → 逐项讨论 → 遗漏/矛盾/可行性检查 → 汇总讨论结论 → 用户方向确认 → 完整设计方案 → 用户设计确认 → 实施。方向确认只授权进入设计；设计确认才授权实施。
• 轻量确认门：局部明确 bug、只读审查或上下文充分的低风险改动，建立轻量 Task Envelope，记录目标与证据、允许与禁止动作、预期产物和完成标准；没有阻塞决定即可执行。
• 轻量任务一旦会改变玩家体验、核心数据契约、跨系统行为或不可逆结构，立即升级到完整确认门。
• 未获相应确认前，不创建正式实现、不为生产方案安装依赖、不确定不可逆架构，也不把灵感或 AI 推荐升级成需求。可行性实验必须经同意并使用隔离、可丢弃的 Probe；Probe 只产生证据，不自动成为正式实现。
• 玩家主权、正式状态一致性、数据安全和来源保留不因任务轻量而被跳过。

铁律 1：单决定单元提问

• 面向小白时从整体走向个体，每轮只推进一个主要决定单元；只有无法分开理解的少量子项可以一起讨论。
• 每次先解释当前决定及其作用，再给 2–3 个可理解方案、实际影响和明确推荐，最后只请用户确认当前决定。若只有一个安全可行方案，如实说明，不制造假选项。
• 不把 RP 内容清单、宿主职责或系统清单一次性抛成问卷；不重复询问已有可靠答案；专业术语先用普通语言解释。
• 用户未回答不等于同意。阻塞决定必须确认；非阻塞缺口可标记 暂定/待讨论 后继续。
• 每完成一组相关决定，汇总 已确定/暂定/待讨论 和当前进度。