---
name: skill-sandbox-expander
description: 沙盘库系统化扩充 Skill。识别各域沙盘覆盖缺口，建议优先场景（优先级：缺失类型>跨域>边界>变体），严格两阶段生成（Phase 1 禁止读 SKILL.md → Phase 2 对照验证），将 status="draft" 补全为 "validated" 或 "gap-found"，持续推进 100 沙盘目标。触发词：「扩充沙盘」「增加沙盘」「写更多沙盘」「沙盘库不够」「填充沙盘覆盖缺口」「把[域名]域的沙盘补到N个」「沙盘数量太少」「补全draft沙盘」「把草稿沙盘补完」「把所有草稿补完」「把draft补成完整版」。
---

# 沙盘库系统化扩充（skill-sandbox-expander）

> 关系类型：depends-on（依赖 DOMAIN-REGISTRY + NODE-IO-CONTRACTS + SANDBOX-FORMAT）
> 关系类型：triggers（Phase 2 读取各域 SKILL.md；结果被 skill-domain-health-check / skill-domain-self-optimizer 消费）
> 强绑定 Rule：R2 NO_FABRICATION / R3 READ_FIRST / R6 ARTIFACT_FIRST / R1 EVIDENCE_FIRST

---

## 核心设计约束（执行前必须理解）

**全量搜索约束（P9? F-021）——与两阶段分离同等优先级**：

沙盘的目标不只是「入口宽度覆盖」（覆盖不同场景类型），还必须保证「链路深度完整性」：
- **对每个入口**：必须追踪完整的使用链路（一次闭环可能有 N 步，必须走完所有步）
- **对每个分叉点**：基于不同反馈会产生不同分支，所有主要分支都必须被覆盖（可以由多个沙盘共同覆盖一个入口的所有分支）
- **一个沙盘 = 一个完整链路实例**：描述某个入口在某种反馈路径下的完整走法，而不是只描述入口和出口

```
❌ 不合格的场景规划：「用户触发产品定义 → 产品经理输出产品定义文档」
✅ 合格的场景规划：
   场景A：用户触发产品定义，第一次问答后用户满意 → 关卡A → 关卡B → 开发
   场景B：用户触发产品定义，关卡A 发现设计漏洞 → 用户修改 → 重新过关卡A → 关卡B → 开发
   场景C：用户触发产品定义，关卡B 发现架构问题 → 回到技术架构师 → 修改 → 重过关卡B
   （三个沙盘合并覆盖「产品定义」入口的全量路径）
```

**Step 3（场景建议）的全量搜索要求**：
- 每个入口节点，首次覆盖时必须建议 2-3 个沙盘（覆盖主链路 + 主要分叉分支）
- 已有沙盘的入口，检查现有沙盘是否已覆盖所有主分支，缺失的分支优先级高于全新入口

**两阶段分离是本 Skill 最关键的第二约束**：

- Phase 1（预想）= 只能读 DOMAIN-REGISTRY + NODE-IO-CONTRACTS + SANDBOX-FORMAT + 已有沙盘 frontmatter（前7行），**禁止打开任何 .cursor/skills/\*/SKILL.md 文件**
- Phase 2（实际验证）= 才可以读对应 SKILL.md 文件

违反这个约束 = Phase 1 被污染 = 沙盘失去验证价值。

**节点→文件路径规则**（Phase 2 使用）：
- 标准 Skill：`.cursor/skills/[Skill目录名]/SKILL.md`（目录名 = DOMAIN-REGISTRY Skill列的值）
- 若文件不存在 → 记为「❌ 缺失节点」Gap，继续其他节点

---

## 执行模式判断（Step 1 开头执行）

```
IF 被其他 Skill 作为子任务调用（子任务模式）：
  → 从调用方传入的参数中读取：域名 + 目标数量 + 模式
  → 参数格式：{ domain: "[域名]", count: [数量], mode: "新增" or "补全draft" }
  → 若 count > 20，自动截断为 20，并在输出中标注「已截断：原参数 count=[原值]，上限为20」
  → 跳过所有「询问用户」和「等待用户确认」的交互步骤，直接执行
  → 跳过 auto-experience-hook 的 Step 3 任务日志写入（由主任务统一记录）

ELSE IF 用户意图为「补全已有 draft」（触发词包含「草稿」「draft」「补完」「补全」之一）：
  → 直接进入模式：跳过 Step 3-4（Phase 1 生成），直接从 Step 5 开始执行
  → 先询问：「请指定域（产品开发/认知结构/公司运营/内容宣传/Skill体系/全部）」
  → 等用户确认后，Step 5 扫描目标域的所有 status="draft" 沙盘作为处理列表

ELSE（用户直接触发新增沙盘）：
  → 执行 Step 1 的交互式询问流程
```

**关于 skill-closure-verifier-meta 的关系澄清**：
verifier-meta Step 4 有自己的 inline Phase 2 逻辑（快速补全 draft 沙盘），与本 Skill 的 Phase 2 是两套独立实现，各自触发：
- verifier-meta inline Phase 2：在全量验证运行中快速补全 draft 状态的沙盘
- 本 Skill Phase 2（完整版）：包含 Gap 证据链要求和质量门槛，用于系统化扩充
两套机制不互相调用，不造成覆盖冲突。

---

## 激活后立即执行

```
Step 1  确认扩充范围（直接触发模式执行；子任务模式跳过）
        
        询问用户：
        (1) 「请指定域：产品开发 / 认知结构 / 公司运营 / 内容宣传 / Skill体系 / 全部」
        (2) 「本次新增几个沙盘？（建议 5-10 个，单次不超过 20 个）」
        
        默认值：
        - 未指定域 → 「全部」
        - 未指定数量 → 5 个（全部域模式下：5 个总数，按缺口最大的域分配；单域模式下：5 个给该域）
        
        输出：确认的处理域列表 + 每域目标新增数量

Step 2  读取覆盖状态（R3 READ_FIRST — 建立事实基础再建议）
        
        并行读取：
        A. _内部总控/skill-system-design/DOMAIN-REGISTRY.md
           → 提取每个目标域的入口节点列表
        B. _内部总控/skill-system-design/SANDBOX-FORMAT.md
           → 确认合法 scenario-type 标签列表
        C. 对每个目标域，扫描 sandboxes/[域]/ 目录：
           → 列出所有已有沙盘文件名
           → 读取每个文件的 frontmatter（前7行），提取 scenario-type 字段
             ⚠️ 只读 frontmatter，不读 Phase 1/2 正文（避免提前了解 Skill 实现细节）
           → 统计各 scenario-type 出现次数
           → 找出最大沙盘序号 NNN（每个域独立计算，互不影响）
        
        输出（必须明确输出，不允许跳过）：
        
        | 域 | 已有沙盘数 | 覆盖的 scenario-type | 缺失的 scenario-type | 下一序号 |
        |---|---|---|---|---|
        
        失败处理：
        - 若某域 sandboxes/[域]/ 目录不存在 → 标记为「目录缺失，跳过该域」
        - 若 DOMAIN-REGISTRY.md 不存在 → 停止执行，告知「基础文档缺失，无法继续」
        - 若 SANDBOX-FORMAT.md 不存在 → 停止执行，同上

Step 3  建议优先场景（⚠️ 此步骤仍禁止读任何 SKILL.md）
        
        基于 Step 2 覆盖状态报告，为每个目标域建议候选场景。
        
        优先级规则（与 description 字段一致，按以下顺序）：
        P1：该域缺失的 scenario-type（完全没有覆盖的类型，效果最显著）
        P1b：已有入口的缺失分支（全量搜索要求：同一入口的不同反馈路径未被覆盖）
             ——分支缺失优先级 = 与 P1 同级，因为入口只有一个沙盘时深度不足
        P2：跨域触发场景（cross-domain），通常现有系统 Gap 密度最高
        P3：边界/异常场景（edge-case），最容易暴露隐藏 Gap
        P4：已有类型的变体场景
            ——变体定义：同一 scenario-type 但不同前置状态或触发时序
            （例：iteration 场景下「文档已有 v1」vs「文档不存在」是两个变体）
        
        ⚠️ 全量搜索检查（每个入口节点执行）：
        对每个被建议场景的入口节点，额外输出：
        - 「该入口当前已有 N 个沙盘，覆盖了分支：[列出]」
        - 「该入口尚未覆盖的主要分支：[列出]」
        - 「本次建议覆盖其中哪个分支，以及是否需要同时建议覆盖其他未覆盖分支」
        
        对每个候选场景，输出：
        - 场景名称（简短）
        - 入口节点 ID（与 DOMAIN-REGISTRY 对应）
        - 场景描述（1-2 句话，不包含 Skill 实现细节）——必须包含「在什么反馈条件下走哪个分支」
        - scenario-type 标签
        - 选择理由
        - 与现有沙盘的本质区别（防止重复，必填）
        - 该入口分支覆盖进度（本次新增后：已覆盖N个分支/估计总分支M个）
        
        ⚠️ 强制确认（直接触发模式）：
        列完候选场景后，询问用户：
        「以上是建议写的 N 个场景，是否全部采纳，或需要调整？」
        等待用户回复：
        - 「继续」「好的」「可以」「全采纳」→ 全部采纳，直接进入 Step 4
        - 「调整第N个」「去掉第N个」「换一个」→ 按用户意见修改对应场景后，重新输出修改后的完整清单，再次询问确认
        - 用户直接给出新场景描述 → 替换对应场景后，再次询问确认
        
        子任务模式：跳过确认，直接采纳全部候选场景。
        
        若某域所有 scenario-type 均已覆盖：
        → 说明「[域名]标准类型已全覆盖，建议写变体场景（见 P4 定义）」
        → 若仍需在该域新增 → 基于 P4 变体规则建议

Step 4  Phase 1 生成（⚠️ 此步骤禁止读 .cursor/skills/*/SKILL.md）
        
        ┌──────────────────────────────────────────────────────────┐
        │ ⚠️ 关键约束：Step 4 执行期间，禁止打开任何              │
        │   .cursor/skills/*/SKILL.md 文件。                       │
        │   仅允许读取：DOMAIN-REGISTRY / NODE-IO-CONTRACTS /      │
        │   SANDBOX-FORMAT（frontmatter读取已在Step2完成）         │
        │                                                          │
        │ ⚠️ context 污染防护：若 AI context 中已存有              │
        │   SKILL-INDEX 的内容（如被上游调用时读取过），           │
        │   生成 Phase 1 时必须显式声明：                         │
        │   「本预想不参考 SKILL-INDEX 中的 description 内容」    │
        │   Phase 2 完成后，额外检查：Phase 1 中是否有任何        │
        │   与 SKILL-INDEX description 字段字面一致的内容         │
        │                                                          │
        │   污染识别：Phase 1 出现「Step X 里有…」               │
        │   「根据 SKILL.md 的步骤…」或与 SKILL-INDEX            │
        │   description 字段高度一致的描述 = 已被污染            │
        │   处理：删除该文件，回到 Step 3 重选场景后重写          │
        └──────────────────────────────────────────────────────────┘
        
        处理范围：Step 2 确认的「目录存在」的域；跳过「目录缺失」的域。
        
        对每个确认的候选场景，按 Step 3 清单顺序执行（不并行，防止序号冲突）：
        
        4.1  从 DOMAIN-REGISTRY.md 读取该场景涉及的节点和触发链路
        4.2  从 NODE-IO-CONTRACTS.md 读取相关节点的 I/O 契约
        4.3  生成 Phase 1 三要素（⚠️ v1.2新增：含用户视角预想和通过判定标准）：
             - 预想触发链路（节点序列 + 每步触发条件）
             - 预想终态输出（具体产物 + 文件路径）
             - 自洽检查点（文档一致性要求）
             - 用户视角预想（4维度）：
               ① 典型触发场景（用户在什么处境下触发这个Skill）
               ② 用户期望的响应（一句话，不是技术输出）
               ③ 用户最容易误触发的情形（触发词盲区）
               ④ 认知根确认（执行者需要哪个 L1/L1.5 文档）
        4.4  按 SANDBOX-FORMAT.md v1.2 写入沙盘文件：
             - 路径：_内部总控/skill-system-design/sandboxes/[域]/sandbox-[NNN].md
             - NNN = 该域 Step 2 确认的下一序号，每写完一个 +1
             - status = "draft"
             - Phase 1 包含：预想触发链路 + 分支覆盖声明 + 预想终态输出 + 自洽检查点 + 用户视角预想
             - Phase 2 包含以下占位结构（待 Phase 2 执行时填写）：
               * 通过判定标准（pre-filled）：「validated门槛：所有节点三项均✅且Gap为零」
               * 节点逐一验证表（行填「— （待 Phase 2 执行）」）
               * Gap 发现（含严重程度列：Critical/High/Medium）
               * 接受风险记录（默认「无接受风险项」）
             - 若目标文件已存在（序号冲突）→ NNN 自动 +1 再写
        
        每写完一个告知：「✅ sandbox-[ID] Phase 1 已写入（status: draft）」
        
        失败处理：
        - 入口节点在 DOMAIN-REGISTRY 中不存在 → 跳过该场景，报告「[节点名]未在节点图中找到」

Step 5  Phase 2 验证（⚠️ 此步骤才允许读 SKILL.md）
        
        处理列表确认：
        - 正常路径（Step 4 后执行）：处理 Step 4 生成的所有 status="draft" 沙盘
        - 直接进入模式（用户说「把草稿补完」）：扫描目标域 sandboxes/[域]/ 目录，
          收集所有 status="draft" 的沙盘文件作为处理列表
        
        对列表中每个沙盘文件，顺序执行：
        
        5.1  读取该沙盘的 Phase 1「预想触发链路」，列出涉及节点
        5.2  读取路径映射（见文档顶部规则）：
             - 标准路径：.cursor/skills/[Skill目录名]/SKILL.md
             - 若文件不存在 → 记为 ❌，继续其他节点
        5.3  逐节点验证三项（每项必须有明确判断，不允许全部标 ✅ 而无说明）：
             
             A. 触发了吗：
                → 读 Skill description 字段的触发词
                → ✅ 触发词明确匹配场景输入
                → ⚠️ 语义相近但不确定（说明不确定原因）
                → ❌ 触发词不匹配或 Skill 文件不存在
             
             B. 输出了吗：
                → 检查 Skill 激活步骤中是否有「写文件/追加/更新」等明确输出操作
                → ✅ 有明确输出步骤（含路径或格式）
                → ⚠️ 有输出但路径/格式模糊
                → ❌ 无明确输出步骤（或只在对话中回复）
             
             C. 触发下游了吗：
                → 检查 Skill 最后步骤中是否有「触发/调用/建议用户做X」等触发下游的语句
                → ✅ 有明确触发步骤
                → ⚠️ 有「建议」但为可选，非强制
                → ❌ 无任何触发下游步骤（终态节点除外）
        
        5.4  识别 Gap：
             对照 Phase 1 预想链路 vs Phase 2 实际验证，差异处 = Gap 候选
             
             每个 Gap 必须满足：
             - Gap 类型（缺节点 / 缺触发条件 / I-O不匹配 / 文档不自洽 / 边界盲区）
             - 证据引用：「[Skill名].SKILL.md [步骤N/description 字段] 中缺少/未定义[具体内容]」
             - 禁止「可能/也许/感觉」类模糊 Gap（R2 NO_FABRICATION）
        
        5.5  更新沙盘文件：
             - 替换 Phase 2 验证表格中的占位行
             - 填写 Gap 发现部分
             - 更新 status：无 Gap → "validated"，有 Gap → "gap-found"
        
        每完成一个告知：「✅ sandbox-[ID] Phase 2 完成，status: [validated/gap-found]」
        
        失败处理：
        - 判断不确定某节点 → 标 ⚠️，备注说明不确定原因
        - 所有节点判断完毕发现「全部 ✅ 无任何 ⚠️/❌」→ 重新审查「触发下游了吗」（这项最常被忽略）

Step 6  输出覆盖缺口更新报告（内联输出，不写文件）
        
        格式：
        
        本次新增：[N] 个沙盘
        - validated（无 Gap）：[X] 个
        - gap-found（有 Gap）：[Y] 个，共发现 [M] 条 Gap
        
        | 域 | 更新前沙盘数 | 更新后沙盘数 | 新增覆盖的 scenario-type |
        |---|---|---|---|
        
        剩余覆盖缺口：
        [各域仍未覆盖的 scenario-type，距 20/域上限还差几个]
        
        本次发现的 Gap 摘要：
        | sandbox-ID | 节点 | Gap 类型 | 一句话描述 |
        |---|---|---|---|
        
        若本次有 gap-found 沙盘（Y > 0），将 Gap 摘要写入持久化文件：
        路径：_内部总控/skill-system-design/gap-summary-[域名]-YYYYMMDD.md
        格式：同上表，追加写入（文件已存在则追加，不覆盖）
        注：此文件供 skill-domain-self-optimizer 跨会话读取，弥补「内联输出仅当次有效」的限制
```

---

## 注意事项

- **Phase 1 污染的识别**：若 Phase 1 中出现任何「Skill 实现步骤」的细节，立即认定为污染，删除重写
- **Phase 2 全 ✅ 预警**：若某沙盘的 Phase 2 节点验证表格中 ⚠️/❌ 为零，强制重新检查「C. 触发下游了吗」——这是最常被标为 ✅ 而实际上是 ⚠️ 的一项
- **序号独立于域**：每个域独立计数，产品开发 PD-006 和认知结构 CS-006 互不干扰
- **文件名格式**：文件名为 `sandbox-[NNN].md`（纯数字，如 `sandbox-006.md`）；沙盘内容 frontmatter 里的 `sandbox-id` 字段含域前缀（如 `PD-006`），两者不要混淆
- **单次 5-10 个原则**：超过 10 个时质量不可控，建议分多次执行

---

## 与其他 Skill 的关系

| Skill | 关系 |
|---|---|
| `skill-closure-verifier-meta` | 独立并行：verifier-meta 有自己的 inline Phase 2（快速版）；本 Skill 是完整版 Phase 1+2，两套机制各自独立触发 |
| `skill-domain-health-check` | 输出消费：本 Skill 新增的 gap-found 沙盘被 health-check Step 6 汇总 |
| `skill-domain-self-optimizer` | 输出消费：本 Skill 的 Gap 摘要是 optimizer 的 Gap 证据库 |
| `DOMAIN-REGISTRY.md` | 必须依赖（Phase 1 节点图来源）|
| `NODE-IO-CONTRACTS.md` | 必须依赖（Phase 1 I/O 来源）|
| `SANDBOX-FORMAT.md` | 必须依赖（文件格式规范）|
| `skill-rule-修改规范` | 区别：后者修改已有 Skill 文件，本 Skill 只创建新沙盘文件 |

---

## 常见失败模式

**失败模式1**：Phase 1 读了 SKILL.md（两阶段污染）
→ 识别：Phase 1 内容中出现「Step X 里有…」「根据 SKILL.md…」
→ 处理：删除沙盘文件，重新执行 Step 4（不返回 Step 3 重选场景）

**失败模式2**：Phase 2 全 ✅ 无 Gap（走过场）
→ 识别：节点验证表格中 ⚠️/❌ 为零，且域内已有沙盘有 Gap 记录
→ 处理：强制重新验证「C. 触发下游了吗」，通常这里有 ⚠️

**失败模式3**：沙盘场景雷同（换皮重复）
→ 识别：Step 3 候选场景没有「与现有沙盘的本质区别」说明
→ 处理：Step 3 强制要求每个候选场景填「本质区别」（缺失则不通过）

**失败模式4**：沙盘 ID 跳号或重复
→ 识别：Step 2 没有 Glob 扫描实际文件，用了记忆中的数量
→ 处理：Step 2 必须扫描 sandboxes/[域]/ 目录文件列表，从文件名解析最大序号

---

## 变更记录

### v1.0 — 2026-03-19 — 初始创建（关卡A修复后版本）

**根因**：沙盘库是全新工件类型，缺乏系统化扩充机制。AI 手动创建时容易违反 Phase 1 不读 SKILL.md 的核心约束，也无法系统识别覆盖缺口。

**关卡A修复内容**（来自 skill-simulator 🔴 问题）：
- 🔴-1：统一优先级体系为 P1>P2>P3>P4（description 字段 + Step 3 正文一致）
- 🔴-2：加入「执行模式判断」（直接触发 vs 子任务调用，子任务模式跳过交互确认）
- 🔴-3：在文档顶部明确「节点→文件路径规则」
- 🟡-1：Step 2 明确只读 frontmatter 前7行，不读正文
- 🟡-2：Step 5 开头增加「处理列表确认」（直接进入模式收集 draft 沙盘）
- 🟡-3：明确「全部域模式下5个为总数，按缺口分配」
- 🟡-4：在 Step 3 中定义「变体场景」
- 🟡-5：Step 4 明确「按 Step 3 清单顺序执行」
- 🔵-1：Step 4 开头明确「处理范围 = Step 2 确认的目录存在域」
- 🔵-2：Step 2 明确「每个域独立计算序号」
- 🔵-3：Step 2 明确「只读 frontmatter，避免间接污染」
- 🔵-4：修正 2.4 依赖声明（SANDBOX-FORMAT 在 Step 2 读，非 Step 1）

**验证状态**：✅ 三关卡全部通过

### v1.0.1 — 2026-03-19 — 关卡B修复（来自 skill-system-destroyer 审查）

**关卡B修复内容**：
- 🔴 C-1：澄清 verifier-meta 与本 Skill 的关系——两套独立实现，不互相调用，消除「承诺了调用但实际无」的声明矛盾
- 🔴 C-2：子任务模式加入 count > 20 自动截断逻辑（上限20个）
- 🟡 W-1：子任务模式跳过 auto-experience-hook 的任务日志（由主任务统一记录，防止日志膨胀）
- 🟡 W-2：Step 6 Gap 摘要改为「内联 + 写持久化文件 gap-summary-*.md」，支持跨会话读取
- 🟡 W-3：Phase 1 约束补充「context 污染防护」（SKILL-INDEX description 字段的隐性污染）

### v1.0.3 — 2026-03-19 — 加入全量搜索原则（F-021/P9?）

**根因**：F-021原则（AI时代全量搜索）写入认知体系，当前Skill只关注「场景类型覆盖宽度」，不要求每个入口的完整链路深度和分支覆盖。

**修改内容**：
- 新增：「全量搜索约束」到「核心设计约束」段首——含示例说明合格vs不合格场景规划
- 修改：Step 3 优先级规则 → 新增 P1b「已有入口的缺失分支」（与 P1 同级）
- 新增：Step 3「全量搜索检查」——每个入口节点必须输出分支覆盖进度

**验证结果**：
- 正向验证：下次触发沙盘建议时，AI对已有入口应输出分支覆盖分析，而不只是建议新类型（待验证）
- 负向验证：两阶段分离约束、Phase 2 验证逻辑不变

**验证状态**：🔵 待验证

### v1.0.2 — 2026-03-19 — 关卡C修复（来自 verifier 验证）

**关卡C修复内容**（场景2失败引起必须修复）：
- ❌ 场景2 触发词缺失：在 description frontmatter 中新增「补全draft沙盘」「把草稿沙盘补完」「把所有草稿补完」「把draft补成完整版」
- ❌ 场景2 直接进入模式未定义为顶层分支：在「执行模式判断」加入第三分支（ELSE IF 用户意图为补全草稿），路由到直接进入 Step 5
- 🟡 场景1 Step 3 部分调整处理：补充「调整第N个/换一个」的修改后再次确认逻辑
- 🟡 注意事项序号格式说明：明确区分文件名（纯数字）和 frontmatter sandbox-id（含域前缀）

---

### v1.0.4 — 2026-03-24 — Step 4.3/4.4 加入 SANDBOX-FORMAT v1.2 新字段

**根因**：SANDBOX-FORMAT.md 升级至 v1.2（2026-03-24 cross-synthesis），新增了4个字段：用户视角预想（Phase 1）、通过判定标准（Phase 2 前置）、Gap严重程度分级（Critical/High/Medium）、接受风险记录。但 skill-sandbox-expander 在 Step 4 生成沙盘时仍使用旧模板，导致新格式规范是「死文档」。

**修改内容**：
- 修改：Step 4.3「生成 Phase 1 三要素」→ 新增「用户视角预想」（4维度）为第4个要素
- 修改：Step 4.4「写入沙盘文件」→ 明确 Phase 1 包含用户视角预想；Phase 2 占位结构加入通过判定标准、Gap严重程度列、接受风险记录

**备份路径**：`history/SKILL_v1.0.3_20260324_before_v12fields.md`

**验证状态**：🔵 待验证