---
name: mc-grill
description: 模组需求拷问（对齐）。当用户提出 Minecraft 模组的新内容、新机制、新玩法且需求未定型时激活，或用户明确说「拷问我 / 帮我理需求 / 先对齐 / grill」时激活。一轮轮提出带推荐答案的问题，把设计树每个分支问到没有默认假设，结束时输出共识清单、等用户确认才动手。不适用于具体 API 签名问答、报错排查、以及指令已明确的精确改动——那些直接回答或直接执行。
---

# mc-grill — 模组需求拷问

目标只有一个：动手之前，「做什么」的每一条分支都由用户拍过板。结束时你应能对任何一条被碰到的分支答出「用户当时怎么定的」；答不上 = 还没拷问到，不许开工。

## 第 0 步 · 先定坐标

开始拷问前确认两件事，它们决定后面哪些问题该问、哪些答案有唯一解：

- 加载器（Forge / NeoForge / Fabric / Quilt / LiteLoader / Rift / ModLoader / 基岩）
- Minecraft 精确版本（不接受「1.20 左右」）

获取顺序：

1. MCP 工具可用 → 调 `detect_mod_project`，要它的判定和证据。
2. 否则只读扫工程元数据：`quilt.mod.json` → NeoForge 标记（`net.neoforged.moddev`、`neoforge.mods.toml`、`net.neoforged.*` 包）→ `fabric.mod.json`（残留文件不得压过 NeoForge / LiteLoader）→ `litemod.json` → `mods.toml` + ForgeGradle → `riftmod.json` → `BaseMod` 且无 FML → 包根 `manifest.json`（基岩）。
3. 定不下 → 这就是本轮第一个问题，只问这一件，内容问题留到下一轮。

平台版本没定，不进入内容拷问：同一个创意在不同平台是完全不同的设计题。工程里若已有平台包（AGENTS.md / rules / skills），先读它，技术枝问题以它的口径为准。

## 第 1 步 · 把需求画成设计树

把用户的一句话（例：「加一个会爆炸的箱子」）展开成决策分支，每条分支标注谁有权定：

- **创意枝 —— 只能用户定**：触发条件、数值与规则（半径 / 伤害 / 是否破坏方块）、掉落与回收、GUI / 音效 / 粒子、与红石和其他模组的交互、平衡代价（合成材料、消耗、冷却）。
- **技术枝 —— 按平台分叉**：要不要方块实体、服务端状态是否需要同步、要产出哪些资源与数据文件（模型 / 配方 / 战利品 / lang 键）。
- **代劳枝 —— 可以不问**：纯 API 写法选择、低风险版本兼容取舍。你直接定，但必须记入「已代劳」清单（理由 + 回退），不得默默执行。

## 第 2 步 · 按 frontier 轮次提问

1. 一轮只问**前置已定**的问题：答案依赖本轮另一条未决问题的，留到下一轮。
2. 每题编号，并附**你推荐的答案**；措辞让用户答「可以」就等于接受推荐。
3. 推荐必须有立场：每题给「推荐 + 一句为什么」。没有立场的问题不如不问。
4. 等本轮答案全部回来，重算 frontier，进下一轮。
5. **能自己查到的事实不问用户**：某类 / 某事件在该平台版本是否存在、配方或 JSON 格式、版本差异——派子代理或调工具去查（有 `search_*_docs` / `query_api` 就用），把查到的写进推荐依据。查不到就在问题里明说「未核实」，禁止编。

## 第 3 步 · 共识清单（结束闸）

frontier 清空 = 没有任何分支还在「被默认」。输出四块：

- **已定**：逐条「决定内容 —— 拍板方式（用户选的 / 用户点头的推荐）」
- **已代劳**：API 与版本取舍 —— 每条附理由 + 怎么回退
- **未核实**：本轮查不到的事实 + 它影响哪个后续决定
- **下一步**：建议进入的工作流或直接改动计划（MCP 可用时可点名 `get_workflow_template` 的模板）

**用户确认这份清单之前，不写代码、不改文件。** 这是本技能唯一硬闸。

## 边界

- 需求本身已清楚、只是实现细节待查 → 不开 grill，直接干。
- 用户中途说「够了 / 别问了」→ 立即停止提问，把未决分支列进「未核实」，按现有共识走。
- 用户在比较多个方案 → 那不是多轮拷问，是原型问题；建议挑一个先 grill，其余各自另开。