菜单
沙盘库系统化扩充 Skill。识别各域沙盘覆盖缺口，建议优先场景（优先级：缺失类型>跨域>边界>变体），严格两阶段生成（Phase 1 禁止读 SKILL.md → Phase 2 对照验证），将 status="draft" 补全为 "validated" 或 "gap-found"，持续推进 100 沙盘目标。触发词：「扩充沙盘」「增加沙盘」「写更多沙盘」「沙盘库不够」「填充沙盘覆盖缺口」「把[域名]域的沙盘补到N个」「沙盘数量太少」「补全draft沙盘」「把草稿沙盘补完」「把所有草稿补完」「把draft补成完整版」。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/TashanGKD/tashan-cursor-skills --skill skill-sandbox-expander命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | skill-sandbox-expander |
| description | 沙盘库系统化扩充 Skill。识别各域沙盘覆盖缺口，建议优先场景（优先级：缺失类型>跨域>边界>变体），严格两阶段生成（Phase 1 禁止读 SKILL.md → Phase 2 对照验证），将 status="draft" 补全为 "validated" 或 "gap-found"，持续推进 100 沙盘目标。触发词：「扩充沙盘」「增加沙盘」「写更多沙盘」「沙盘库不够」「填充沙盘覆盖缺口」「把[域名]域的沙盘补到N个」「沙盘数量太少」「补全draft沙盘」「把草稿沙盘补完」「把所有草稿补完」「把draft补成完整版」。 |
关系类型：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）——与两阶段分离同等优先级：
沙盘的目标不只是「入口宽度覆盖」（覆盖不同场景类型），还必须保证「链路深度完整性」：
❌ 不合格的场景规划：「用户触发产品定义 → 产品经理输出产品定义文档」
✅ 合格的场景规划：
场景A：用户触发产品定义，第一次问答后用户满意 → 关卡A → 关卡B → 开发
场景B：用户触发产品定义，关卡A 发现设计漏洞 → 用户修改 → 重新过关卡A → 关卡B → 开发
场景C：用户触发产品定义，关卡B 发现架构问题 → 回到技术架构师 → 修改 → 重过关卡B
（三个沙盘合并覆盖「产品定义」入口的全量路径）
Step 3（场景建议）的全量搜索要求：
两阶段分离是本 Skill 最关键的第二约束：
违反这个约束 = Phase 1 被污染 = 沙盘失去验证价值。
节点→文件路径规则（Phase 2 使用）：
.cursor/skills/[Skill目录名]/SKILL.md（目录名 = DOMAIN-REGISTRY Skill列的值）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 是两套独立实现，各自触发：
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 跨会话读取，弥补「内联输出仅当次有效」的限制
sandbox-[NNN].md（纯数字，如 sandbox-006.md）；沙盘内容 frontmatter 里的 sandbox-id 字段含域前缀（如 PD-006），两者不要混淆| 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/[域]/ 目录文件列表，从文件名解析最大序号
根因：沙盘库是全新工件类型，缺乏系统化扩充机制。AI 手动创建时容易违反 Phase 1 不读 SKILL.md 的核心约束，也无法系统识别覆盖缺口。
关卡A修复内容（来自 skill-simulator 🔴 问题）：
验证状态：✅ 三关卡全部通过
关卡B修复内容：
根因：F-021原则（AI时代全量搜索）写入认知体系，当前Skill只关注「场景类型覆盖宽度」，不要求每个入口的完整链路深度和分支覆盖。
修改内容：
验证结果：
验证状态：🔵 待验证
关卡C修复内容（场景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 生成沙盘时仍使用旧模板，导致新格式规范是「死文档」。
修改内容：
备份路径：history/SKILL_v1.0.3_20260324_before_v12fields.md
验证状态：🔵 待验证