| 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
验证状态：🔵 待验证
