调整策划分册结构适配规则

允许按游戏规模和用户要求增减章节与字段。

放宽循环、系统和 TDD 的固定数量与结构要求。

apps/ai-game-creator-shell/src-tauri/design-agent/resources/skills/architecture.md

@@ -13,10 +13,13 @@ description: 写游戏策划案（GDD）系统架构时使用。在顶层设计
 > 本文件是系统架构层唯一承载写作流程的教学件。
 > 模板与例子文件保持纯净：不含任何步骤、检验提示与标记。
 
+## 〇、结构适配原则
+
+本分册的章节、字段和数量是参考结构，不是固定清单。先根据游戏类型、项目规模、用户要求和顶层设计判断适用项：适用项写入，同类项可合并，若某项对本项目没意义则省略；复杂项目可以拆分补充，简单项目可以压缩为最小可用架构。
+
 ## 一、这一层的判断立场
 你是架构师，切系统的刀在你手里。在这个层里你相信：
-- 切分是为了**职责清晰、可独立讨论**，不是为了凑数量——每个系统必须能
-  一句话答出"删了它，什么塌"（P0 原因）。
+- 切分是为了**职责清晰、可独立讨论**，不是为了凑数量。只有确实需要独立职责、状态或数据边界的部分才拆成系统；每个实际拆出的系统应能说明删除后的影响。
 - **数据所有权唯一**：同一事实只由一个系统维护，其他系统只引用稳定 ID，
   不复制主数据。两个系统管同一件事 = 架构事故。
 - **依赖无环**是硬要求；信息呈现层只读状态、只经行动入口写入。
@@ -32,7 +35,7 @@ description: 写游戏策划案（GDD）系统架构时使用。在顶层设计
    然后往 templates/architecture.md 里填。
 3. 记住顶层的核心循环图——切完必须跑覆盖检查。
 
-## 三、十二节总览：写什么、为什么、怎么咬合
+## 三、架构设计的组织维度：写什么、为什么、怎么咬合
 
 架构文档回答四个问题：
 **这个架构为什么这样切（1~3）→ 系统是什么、怎么连接（4~6）→
@@ -88,7 +91,7 @@ description: 写游戏策划案（GDD）系统架构时使用。在顶层设计
 Sxx 编号清单（核心系统通常 1-5 个，有明确要求可超出 5 个）+ 支撑层（存档/UI，不拥有核心规则）。
 P0 段五列表：
 | 系统 | 目的 | 输入 | 输出 | P0 原因 |
-→ 每行 P0 原因必须答"删了它，__ 塌"；答不出的降级或合并。
+→ 对实际拆出的系统说明删除后的影响；无法形成独立职责的部分合并，不为满足数量新增系统。
 
 ### 3. 系统职责
 | 系统 | 主要职责 | 不负责 → 移交谁 |

apps/ai-game-creator-shell/src-tauri/design-agent/resources/skills/concept.md

@@ -13,6 +13,10 @@ description: 写游戏策划案（GDD）概念层时使用。把一句话游戏
 > 本文件是概念层唯一承载写作流程的教学件。
 > 模板与例子文件保持纯净：不含任何步骤、检验提示与标记。
 
+## 〇、结构适配原则
+
+本分册的章节、字段和数量是参考结构，不是固定清单。先根据游戏类型、项目规模、用户要求和上层已定范围判断适用项：适用项写入，同类项可合并，若某项对本项目没意义则省略；复杂项目可以拆分补充，简单项目可以压缩为最小可用规格。
+
 ## 一、这一层的判断立场
 你是资深游戏策划，看过上千份概念案，清楚绝大多数死在"什么都说、什么都不尖"。
 在这个层里你相信：
@@ -31,7 +35,7 @@ description: 写游戏策划案（GDD）概念层时使用。把一句话游戏
    然后往 templates/concept-design.md 里填。
 3. 零参照时在文档头注明"零参照"。
 
-## 三、九节总览：写什么、为什么、怎么咬合
+## 三、概念设计的组织维度：写什么、为什么、怎么咬合
 
 概念文档回答四个问题：
 **这是什么（1~5）→ 它不是什么（6）→ 它靠什么让人一直玩（7）→
@@ -50,7 +54,7 @@ description: 写游戏策划案（GDD）概念层时使用。把一句话游戏
 | 6 | 不是什么 | 负面定位表：不是 X，因为 Y | 正面定义写多必然发散；负面定位用"误会方向+封死原因"收边界，比光秃的非目标锋利一档 | 2 的非目标与跑偏风险的表化展开；与 5 的防串味声明呼应 |
 | 7 | 核心张力 | 玩家持续面对的两难，两端各有代价 | 长期游玩的根本动力；没有张力，再丰富的内容玩几次就腻 | **向下接口**：每条张力必须在顶层变成取舍表里的具体决策 |
 | 8 | 边界与约束 | 本层只定什么、什么留给后面 + 规模回流 | 防止概念层越层写数值和系统（越层是下游返工之源）；给写作画线 | 保护 2 的纯度；告诉顶层"你们的地盘从哪开始" |
-| 9 | 概念定稿 | "核心不是 __ 而是 __"重述 + 给顶层的硬约束 | 收口重锤：写完九节重述一遍，检验整份文档有没有写散；把承诺变成对下的契约 | 回环呼应 1；把 8 的交接具体化成 2~4 条硬约束 |
+| 9 | 概念定稿 | "核心不是 __ 而是 __"重述 + 按需记录给顶层的约束 | 收口并检查概念是否写散；把承诺转成对下的契约 | 回环呼应 1；把边界和交接约束传给下一层 |
 
 咬合一图：
 
@@ -80,7 +84,7 @@ description: 写游戏策划案（GDD）概念层时使用。把一句话游戏
 **定调记录**（全项目调性真源，此节定死）：
 - 参照选择：以 __ 为主、__ 学 __（参照即定调，选完调性随之而来）。
 - 调性滑杆：压力感/战斗比重/管理深度/叙事比重/节奏，各一档。
-- 调性锚 T 原则：3~7 条逐条具名（如"T2 不劝退——凡惩罚类问题默认取最轻档"）。
+- 调性锚 T 原则：按项目需要提炼并逐条具名（如"T2 不劝退——凡惩罚类问题默认取最轻档"）。
   检验：每条 T 都能当一句 IF-THEN 用——"凡__类问题默认__"；写不出口径的 T 是空话。
   → 下游每个开放问题先来这里级联批量起草，级联不了的才升级提问。
 **设计锚点（六项，争议时的仲裁原则，全部具名）**
@@ -112,8 +116,7 @@ description: 写游戏策划案（GDD）概念层时使用。把一句话游戏
 ### 7. 核心张力
 - __ 有限，但 __。
 - __ vs __（两端的代价各是什么）。
-→ 每条两端都必须有代价，只有一端的"假张力"删掉。这些是顶层取舍表的
-  种子，后面要逐条对应。
+→ 如果项目存在核心张力，保留的每条张力都应说明双方代价；没有形成有效张力时，不为了满足结构新增张力。这些是顶层取舍表的种子，后面按需对应。
 
 ### 8. 边界与约束
 - 概念边界放首位：本层只定幻想、用户、基调与排除方向；具体数值、
@@ -124,7 +127,7 @@ description: 写游戏策划案（GDD）概念层时使用。把一句话游戏
 ### 9. 概念定稿（收口重锤）
 这个游戏的核心不是 __，而是：
 > （一句话重述核心承诺）
-交给下一层的约束：__ 必须 __（2~4 条，顶层必须围绕它们展开）。
+交给下一层的约束：按项目需要记录，顶层据此展开。
 
 若某节对本项目没意义，直接省略。
 

apps/ai-game-creator-shell/src-tauri/design-agent/resources/skills/systems.md

@@ -12,6 +12,10 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪
 > 本文件是系统文档层的总纲；各系统的专属写法在 `modules/system-types/` 下对应目录的 `SKILL.md`，
   专属模板在 `modules/system-types/` 对应目录的 `模板.md`。通用纪律不在各系统 skill 里重复。
 
+## 〇、结构适配原则
+
+本分册的章节、字段和数量是参考结构，不是固定清单。先根据系统类型、实际复杂度、用户要求和架构职责判断适用项：适用项写入，同类项可合并，若某项对本系统没意义则省略；复杂系统可以拆分补充，简单系统可以压缩为最小可执行规格。
+
 ## 一、这一层的判断立场
 你是写单个系统的策划。在这个层里你相信：
 - 系统文档是**执行层**：刀已经在架构层切好——服从系统地图编号、职责表
@@ -20,7 +24,7 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪
   防返工价值最高的几行。
 - 接口纪律：引用具名系统与具名数据，禁泛称；别家主数据只引 ID 不复制。
 - 字段定义、数值配置、表结构不归你——写交接声明，交技术文档层（数值策划）。
-- 所有系统同构：读者读熟一份就能读所有份。
+- 系统文档保持基本可读的一致性，但不要求所有系统使用相同章节；结构应服从系统类型和实际行为。
 
 ## 二、动笔前
 1. 架构已定稿：找到本系统的 Sxx 编号、职责表行、依赖方向——这是合同。
@@ -43,7 +47,7 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪
 | 5 | 取舍表 | 玩家在本系统内的决策 | 张力在系统内的落地 | 概念张力→顶层取舍表→本表 |
 | 6 | 状态与规则 | 对象/状态/转换/异常，枚举表达 | 定性规则真源 | 架构职责表对齐 |
 | 7 | 数值与数据交接 | 本系统交 TDD 的数据类别+定性约束 | 分层边界 | 技术文档层承接 |
-| 8 | 反馈 | 何时/何强度/何通道 | 无反馈=没发生 | 顶层反馈四层 |
+| 8 | 反馈 | 关键结果何时、以何种方式反馈 | 让实际结果可理解 | 与本系统实际结果对应 |
 | 9 | 内部循环 | 本系统内的小循环 | 系统自己的心跳 | 顶层小循环的组成 |
 | 10 | 输入、输出与依赖 | 消费/交付/依赖谁 | 接口真源 | 架构依赖图逐边对齐 |
 | 11 | 边界与非目标 | 不负责什么→移交谁 | **防返工价值最高** | 架构职责表"不负责"列 |
@@ -57,12 +61,12 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪
 
 1 系统目的：若删除它，__ 会塌——一句话说不出 = 该系统不该存在。
 2 支撑体验：对应顶层目标第__条、调性原则第__条。
-3 进入与退出：常规进入/读档恢复/特殊事件后返回，三入口必写。
-4 玩家行动：≥4 个具名动词组；编排类写"安排"动词，活动类写"操作"动词。
+3 进入与退出：按本系统实际存在的入口、退出和恢复路径记录。
+4 玩家行动：记录本系统实际存在的具名动词组；编排类写"安排"动词，活动类写"操作"动词。
 5 取舍表：决策/立即收益/延迟收益/主要代价；挂顶层张力编号。
 6 状态与规则：对象-状态-转换-异常，全部枚举表达，不许整段散文。
 7 数值与数据交接：列数据类别名 + 设计侧定性约束；字段定义归 TDD。
-8 反馈：每种关键结果给独立反馈形态；失败必须说明原因和恢复路径。
+8 反馈：记录本系统关键结果的可理解反馈；存在失败时说明原因和恢复路径。
 9 内部循环：动词链；可拆单次/区域/长期三层。
 10 输入输出与依赖：引用具名系统与具名数据，禁泛称"资源"。
 11 边界与非目标：参考该类型 skill 的“三不”说明边界；建议说明字段与数值的交接边界。

apps/ai-game-creator-shell/src-tauri/design-agent/resources/skills/tdd.md

@@ -12,12 +12,16 @@ description: 写游戏技术文档（TDD）时使用的总纲。GDD 四层定稿
 > 本文件是 TDD 层唯一承载写作流程的教学件；各分册 SKILL 与模板配套使用。
 > 模板与例子文件保持纯净：不含任何步骤、检验提示与标记。
 
+## 〇、结构适配原则
+
+本分册的文档件、章节、字段和数量是参考结构，不是固定清单。先根据当前版本的实现目标、游戏规模、运行时和用户要求判断适用项：适用项写入，同类项可合并，若某项对本项目没意义则省略；复杂项目可以拆分补充，简单项目可以合并为最小施工合同。
+
 ## 〇、TDD 的完成判据（总纲）
 
-**TDD 是自足构建包：一个施工 agent 只看 TDD，就能做完完整游戏。**
+**TDD 是当前版本的施工合同：施工方只看 TDD，应能完成本项目实际范围内的实现。**
 GDD 是设计真源（给人看、给迭代看）；TDD 是构建真源（给施工看）。
-检验方式＝自足性检查（见总册）：不看 GDD 能否回答——每个系统怎么行为、
-每张表多少行内容、每个界面怎么走、每份素材什么规格。答不出的项就是缺口，
+检验方式＝按项目范围检查施工所需信息是否齐全：实际存在的系统怎么行为、
+实际使用的表和配置怎么读取、实际存在的界面怎么走、实际需要的素材什么规格。答不出的项就是缺口，
 缺口回 GDD 同步后**收编**进 TDD（带版本锁）。收编是构建期快照：GDD 定稿
 变更 → 触发对应收编节重同步（与 fast_gdd 投影同一机制，方向相反）。
 

apps/ai-game-creator-shell/src-tauri/design-agent/resources/skills/top_design.md

@@ -13,6 +13,10 @@ description: 写游戏策划案（GDD）顶层设计时使用。在概念层定
 > 本文件是顶层设计唯一承载写作流程的教学件。
 > 模板与例子文件保持纯净：不含任何步骤、检验提示与标记。
 
+## 〇、结构适配原则
+
+本分册的章节、字段和数量是参考结构，不是固定清单。先根据游戏类型、项目规模、用户要求和概念层定稿判断适用项：适用项写入，同类项可合并，若某项对本项目没意义则省略；复杂项目可以拆分补充，简单项目可以压缩为最小可用规格。
+
 ## 一、这一层的判断立场
 你是资深游戏策划，正在写全 GDD 最重要的一份文档——概念说"凭什么成立"，
 顶层说"好玩在哪"。核心循环无趣，后面写再多系统也救不回来。在这个层里你相信：
@@ -28,9 +32,9 @@ description: 写游戏策划案（GDD）顶层设计时使用。在概念层定
 1. 概念层 design.md 已定稿可用——顶层定位与取舍表直接从它长出来。
 2. 读 exemplars/stardew-top-design.md 做质量锚（模仿密度，不抄内容），
    然后往 templates/top-design.md 里填。
-3. 把概念层的核心张力清单摊开放在手边——取舍表必须逐条挂上编号。
+3. 把概念层已确认的核心张力作为输入；存在对应取舍时再挂上编号。
 
-## 三、十六节总览：写什么、为什么、怎么咬合
+## 三、顶层设计的组织维度：写什么、为什么、怎么咬合
 
 顶层文档回答四个问题：
 **玩家在玩什么（1~9）→ 玩家面对什么选择与后果（10~11）→
@@ -43,14 +47,14 @@ description: 写游戏策划案（GDD）顶层设计时使用。在概念层定
 |---|---|---|---|---|
 | 1 | 顶层定位与规模锚点 | 承概念定稿 + "让玩家每天都在想"念头句 + 不是X不是Y + 规模参数表（循环单位/段落/复杂度/长期主轴） | 循环单位定错全盘错；定位句防止顶层漂离概念 | 承概念层"概念定稿"；念头句是概念层玩家念头的时间维度版 |
 | 2 | 设计目标 | 几种回报、如何互相供给 | 回报并列=小游戏拼盘；互相供给才是循环 | 供给关系落到 4~5 的循环里 |
-| 3 | 核心推动力 | 动机主次 + 即时/日程/季节/长期四层推动 | 玩家"什么时候被什么推着走"的完整图谱 | 时间四层对应 10 节奏结构的四层 |
+| 3 | 核心推动力 | 按项目实际存在的即时、阶段或长期推动力组织 | 玩家"什么时候被什么推着走"的推动结构 | 与实际节奏结构对应 |
 | 4 | 大循环 | 跨较长时间的循环：文字箭头 + 核心循环图 | 长期留存的结构骨架 | 与 5、7 三层互检：大循环的每环应有小循环供血 |
-| 5 | 小循环 | 几十秒到几分钟的具名动词链 ×3+ | 真正被玩到的那层；动词链可直接复制进实现 | 检验：删掉某条，游戏是否少了一块可命名的乐趣 |
-| 6 | 资源流与输入输出 | 资源流图（来源→储存→消耗）+ 输入输出清单 + 反馈四层 | 资源是循环的血液；防白给、防废物、防套利 | 供血给 4~5 的每个循环环节 |
+| 5 | 小循环 | 按项目实际存在的局内或短周期动词链组织 | 记录真正被玩到的循环 | 按实际循环层级互检 |
+| 6 | 资源流与输入输出 | 按项目实际存在的资源流、输入输出和反馈组织 | 说明循环中的实际供给与结果 | 与实际循环环节对应 |
 | 7 | 最小体验单位 | 多短一段玩法就能体现独有乐趣 + 反馈铁律 | 原型只做这一个单位——定原型规模 | 是 5 的最小切片；14 验证标准的试验对象 |
 | 8 | 核心活动流程 | 段落表：阶段/玩家行为/**设计目的** | "玩这个游戏的一天"的可复述剧本 | 设计目的列写不出的段=该删的段 |
 | 9 | 取舍表 | 决策/立即收益/延迟收益/主要代价 | 张力的具体化——玩家决策的路口 | **逐条对应概念层核心张力**（对上接口） |
-| 10 | 节奏结构 | 日内/周内/季节/长期四层 + 情绪摆动 | 防止"一直紧张"或"一直平"；摆动才有呼吸 | 四层对应 3 的推动力四层 |
+| 10 | 节奏结构 | 按项目实际存在的时间层级和情绪变化组织 | 说明玩法节奏如何变化 | 与实际推动力层级对应 |
 | 11 | 失败与回收 | 亏损定性 + 情况/结果表 | 失败的形态决定调性——"少拿"还是"毁掉" | 对齐概念层情绪基调的边界句 |
 | 12 | 系统范围 | 系统/顶层目的/**边界** 表 | 架构层接口：系统地图的种子 | **对下接口**：架构照此拆系统 |
 | 13 | 范围与非目标 | 最小完整版本清单 + 不做清单 | 立项交付物的边界 | 承概念层"不是什么"；给 14 提供验证范围 |
@@ -96,24 +100,24 @@ description: 写游戏策划案（GDD）顶层设计时使用。在概念层定
 ### 3. 核心推动力
 - 动机主次：__。
 - 即时推动 __；日程推动 __；季节推动 __；长期推动 __。
-→ 四层都要有实指；空着的那层就是将来留存崩塌的地方。
+→ 只展开项目实际存在的时间层级；不存在的层级不设字段。
 
 ### 4. 大循环
 **__ → __ → __ → __ → 回到 __。**（附核心循环图）
 → 检验：断掉任何一环，后面是否塌；每一环应有对应小循环供血。
 
-### 5. 小循环（具名动词链 ×3+）
+### 5. 小循环（按项目实际数量）
 **__循环**：__ → __ → __ → __ → __。
 → 必须具名（"农务循环"不是"资源循环"）；动词链完整到可以直接照做。
 
 ### 6. 资源流与输入输出
 （资源流图：每种核心资源 来源 → 储存 → 消耗 三段全）
-主要输入 __；主要输出 __；反馈四层：立即 __ / 短期 __ / 中期 __ / 长期 __。
+主要输入 __；主要输出 __；按项目需要记录反馈层级。
 → 三问：这资源哪来的？存在哪？花在哪去？答不出=资源设计未完成。
 
 ### 7. 最小体验单位
 __（多短一段玩法体现独有乐趣——原型只做这一个单位）。
-单个行动必须至少提供一种清晰反馈：资源/进度/能力/关系/信息/视觉状态之一。
+保留的玩家行动应有与玩法相称的可理解反馈；反馈形式和数量按项目决定。
 
 ### 8. 核心活动流程（段落表）
 | 阶段 | 玩家行为 | 设计目的 |