xu-jin-cs idea-forge — 设想锻造炉
把用户的一句话设想锻造成缜密可落地的完整设计。用户负责出题（"能不能设计一个……"），本技能负责补齐骨架与血肉。
何时触发
用户输入是设想而非任务时：包含"能不能设计/我有个想法/有没有可能/是不是可以"等构想句式，且对象是一个机制/规则/Agent/流程，而非具体执行请求。
反触发：用户给了明确执行指令（"把 X 改成 Y"）→ 不经过本技能，直接干活。
核心流程（4 步）
Step 1 · 抽取已有要素
从用户的粗糙表述中抽出已经给定的设计要素，哪怕只有一两个词（如"两个槽""广而大窄而深""不强迫"）。这些是设计的锚点，后续补齐不得与锚点冲突。
Step 2 · 按 11 维清单逐项补齐
| # | 维度 | 必须回答的问题 | 空缺时的补齐动作 |
|---|---|---|---|
| 1 | 定位与边界 | 这是什么？明确不管什么？ | 补一句"本机制不做 XX" |
| 2 | 维度/分类 | 分几类几轨？分类标准？ | 给出候选分类轴，选最贴用户表述的 |
| 3 | 颗粒度 | 每类多粗多细？粒度判定标准？ | 补粒度判定规则（如"抽掉项目名还成立吗"） |
| 4 | 触发 | 何时激活？频率预期？豁免场景？ | 补触发条件 + 至少一条豁免（防止形式主义空转） |
| 5 | 执行 | 激活后怎么做？深度？完成标准？禁止行为？ | 补执行语义 + 完成判据 + 至少一条禁止项 |
| 6 | 写法/表述 | 命名规范？文档结构？契约字段？ | 补命名约束 + 最小字段集 |
| 7 | 门禁/判定 | 什么算合格？什么打回？ | 补 2~3 道可机械检查的闸 |
| 8 | 强制 vs 选择性 | 哪些必须做？哪些评估后决定？ | ⚠️ 禁止擅自决定，列入 Step 3 提问 |
| 9 | 留痕/落盘 | 记录到哪？什么格式？谁可读？ | 补落盘路径 + 格式（jsonl/md/json） |
| 10 | 演化路径 | 怎么晋升/降级/淘汰/合并？ | 补双向通道（如攒量晋升 / 选择性催生） |
| 11 | 体系挂载 | 挂在现有哪个体系上？依赖谁？被谁依赖？冲突怎么办？ | 检索现有技能/规则，给挂载点 |
Step 3 · 关键决策点提问（不可跳过）
以下内容用户的偏好无法从设想推断，必须问，禁止替用户拍板：
- 某环节是强制还是选择性（用户历史偏好：倾向选择性+留痕，但仍须确认）
- 是否允许豁免/跳过，豁免条件是什么
- 粒度偏严（多打回）还是偏松（多放行）
- 落地形态：规则文件 / Kimi Code 技能 / 仅口头约定
Step 4 · 输出设计稿
按下方模板输出，每一条标注来源：
[锚]= 用户原话给定的要素，不可违背[补]= 系统补齐的要素，用户可推翻[问]= Step 3 确认后的决定
输出模板
# <机制名> 设计稿 v0.1
## 一句话定位 [锚/补]
## 边界（不做什么） [补]
## 分类与颗粒度 [锚/补]
## 触发（含豁免） [补]
## 执行语义（深度/完成标准/禁止项） [补]
## 写法规范（命名/字段） [补]
## 门禁（N 道闸，可机械检查） [补]
## 强制与选择性清单 [问]
## 留痕（路径/格式） [补]
## 演化路径（晋升/淘汰） [补]
## 体系挂载点 [补]
## 落地动作（写哪个文件/改哪条规则） [问]
内置设计偏好画像（从历史协作沉淀，仍需当次确认）
用户过往的明确偏好，补齐时默认对齐但不替代提问：
- 倾向选择性而非强迫："留接口""评估后决定""不需要也是合法结论"
- 禁止凑数与形式主义：零变更要豁免、为好看而写视同垃圾
- 凡评估必留痕：哪怕结论是"不做"，评估备注必须写
- 双向演化：机制要有向上晋升与向下催生的通道
- 兜底不交白卷：宁可给次优结果+提示，不空手
- 密度优先：规则要能机械检查，忌讳"要注意""要做好"式空话
质量自检（输出前过一遍）
- 11 维每维都有内容，无"待定"空壳
- 每条都标了 [锚]/[补]/[问]
- 强制/选择性全部经过用户确认，无擅自拍板
- 至少 1 条豁免 + 1 条禁止项 + 1 条兜底
- 门禁是可机械检查的（有明确判据），不是形容词
- 与现有体系无冲突，挂载点明确