Menu
复杂任务前置反复盘问用户需求直到无歧义，输出 docs/requirements/<feature>.md 作为后续 plan/实施的事实来源。**触发场景**：用户给一句话模糊需求（如「优化购物车」「改下登录」「看看那个东西」）/ 复杂任务（判据见 im-agent-workflow.md 的「任务复杂度分级」表）/ 未提供 PRD / Figma / 飞书需求的需求；5 轮硬上限不收敛就停下让用户线下整理。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | grill |
| description | 复杂任务前置反复盘问用户需求直到无歧义，输出 docs/requirements/<feature>.md 作为后续 plan/实施的事实来源。**触发场景**：用户给一句话模糊需求（如「优化购物车」「改下登录」「看看那个东西」）/ 复杂任务（判据见 im-agent-workflow.md 的「任务复杂度分级」表）/ 未提供 PRD / Figma / 飞书需求的需求；5 轮硬上限不收敛就停下让用户线下整理。 |
| argument-hint | ["需求描述"] |
| allowed-tools | Read, Write, Bash(mkdir *) |
复杂任务前置：反复盘问用户需求，直到无歧义，输出 docs/requirements/<feature>.md 作为后续 plan/实施的事实来源。
| 任务类型 | 是否需要 grill |
|---|---|
| 简单需求（改注释 / 调样式 / 单文件 fix） | ❌ 不需要，直接做 |
| 中等需求（2-3 文件改、加个 utils） | △ 可选，看需求是否明确 |
复杂需求（判据见 .claude/rules/im-agent-workflow.md 的「任务复杂度分级」表） | ✅ 强烈建议先 grill |
| 一句话模糊需求（"优化购物车" / "改下登录"） | ✅ 必须 grill |
如果用户已经提供详细文档（PRD / 飞书需求 / Figma 链接），先 Read 这些资料，再用 grill 补齐缺失维度。
$ARGUMENTS — 用户的原始需求描述（一句话或一段话）
询问用户是否有：
如有 → Read 后跳到 Step 2 补缺失维度。 如无 → 直接进 Step 1。
从 $ARGUMENTS 提取：
如果完全无法提取（例如 "看看那个东西" 这种），直接返回："需求太模糊，能否换种说法？给我一个动词 + 对象。"
每轮聚焦一个维度提问，禁止漫无目的发散。每轮提问后展示当前理解，让用户确认/修正。
具体改什么？
你说"<原始需求>"，我需要先确认改的范围：
- 是 <候选 A>，还是 <候选 B>，还是 <候选 C>？
- 涉及的文件大概在 <猜测路径>，对吗？
举例：
哪些不改？
这次改动：
- ✅ 我会处理：<列点>
- ❓ 这些是否包含：<候选边界>
- ❌ 我不会动：<显式排除>
确认一下范围对不对？
特别问：
什么场景下生效？
这个改动什么场景下用户会看到？
- 登录态 / 游客？
- 特定路由 / 全站？
- 某个状态下（首次进入 / 数据为空 / 接口失败）？
不正常情况怎么办？
异常情况：
- 接口失败：显示错误提示？回退到默认状态？还是静默？
- 数据为空：空状态文案？还是不渲染？
- 网络慢：loading 态怎么展示？
- 用户没权限：提示登录？还是隐藏入口？
前端的核心——你怎么判断改对了？
我改完后，你怎么验证：
- 我应该让你点哪个按钮 / 进哪个页面？
- 你期望看到什么变化？
- 有什么之前没有的现象现在应该出现？
- 有什么之前的现象现在不应该出现？
这一步是产出 手测步骤 的核心，决定 docs/requirements/ 里"验收清单"章节的内容。
如果到了第 5 轮还有维度没问清：
不要继续问。直接告诉用户：
我们已经讨论了 5 轮但 <维度 X> 还没明确。这通常说明需求本身需要先线下整理。建议：
1. 你先把 <维度 X> 的几种方案列出来
2. 或者先做一个最小可行版本，跑起来看效果再迭代
3. 或者跳过 grill 直接让我按当前理解做（风险：可能返工）
你想怎么办？
理由：5 轮还问不清说明需求本质模糊，AI 继续问只会消耗信任，不会产生新信息。
确认所有维度后，写入 docs/requirements/<kebab-feature>.md。如果目录不存在，先 mkdir -p docs/requirements。
文件模板：
# 需求：<一句话标题>
> 生成时间：<YYYY-MM-DD>
> 来源：用户原话 "<$ARGUMENTS>"
## 目标
<用户真正想要什么 — 1-2 段，禁止空话>
## 范围
### 包含
- <列点>
- <列点>
### 不包含
- <显式排除项>
## 触发条件
- 用户场景：<什么角色 / 什么状态 / 什么路由>
## 异常处理
- 接口失败：<期望行为>
- 数据为空：<期望行为>
- 其他边界：<期望行为>
## 验收清单（手测步骤）
按顺序操作，每步必须是可在浏览器中观察到的现象：
1. <步骤> → 期望看到 <现象>
2. <步骤> → 期望看到 <现象>
3. ...
## 已确认的边界条件
- <从 grill 中确认的关键约束 / 默认值 / 与现有功能的关系>
## 后续动作建议
- 涉及文件预估：<根据 .ai/INDEX.md 路由的相关文件，可空>
- 建议复杂度：简单 / 中等 / 复杂
- 建议下一步：/start-task <branch-name> 或直接开干
需求已澄清，写入：docs/requirements/<feature>.md
接下来：
- 复杂任务：建议 /start-task feat/<feature> 创建分支后开始
- 中等任务：可以直接开始改，参考 verifyClist 验收
- 不确定：把 requirements.md 给到 planner agent 让它出 plan
| 关系 | 说明 |
|---|---|
| 上游：用户原始需求 | grill 是把模糊需求转成结构化文档的入口 |
| 下游：planner agent | planner 必须先 Read requirements.md，plan 不能引入 requirements 外的假设 |
| 下游：test-assist skill | "验收清单"是 test-assist 写测试时的覆盖参考 |
| 下游：dev-debug skill | "手测步骤"是 dev-debug 启动浏览器后的检查清单 |
| 旁路：Figma / 飞书 | grill 不替代视觉设计；有 Figma 链接先看图，再 grill 补维度 |
在任意空目录中从零创建数字人智能体应用。自动识别场景（业务流/纯对话/能力展示），从内置模板复制项目文件，引导用户改配置、本地调通。Use when 用户说"新建数字人应用""开发智能体""做 XX 场景的 Demo""搭一个数字人""创建一个数字人项目"。
接到"加 Biz 类型 / 加新消息类型 / 加新消息样式 / 发某某卡片 / 想发个表单让用户填 / 消息发出去对端没收到"等需求时触发。引导决策：基础类型 vs 已有 BIZ vs 新增 BIZ；新增 BIZ 必须走后端专属接口 + 前后端共同约定 4 步流程；前端职责仅"调发送接口 + 写展示卡片"。
合并 master 前检查 swagger-repo.json 是否残留 feat 分支，半自动逐条切回并重跑 gen:api。**触发场景**：准备合并到 master 之前（由 git-ship skill 自动调用）/ 修改过 swagger-repo.json 的 branch 字段 / 拉到陌生分支后想确认 API 类型来源 / 用户输入 /check-api-branch。
多模型并行 Code Review。**自动触发场景**：用户拍板 plan 后改完代码（中等 / 复杂任务），AI 主动询问「需要 code review 吗？」**手动触发**：用户输入 `/code-review` 或说「review 一下这次改动 / 帮我看看这次提交」。按改动复杂度分级派 SubAgent，**轻量改动只派 1 个 sonnet 兜底，复杂任务才派 3 个含 opus 架构师**——不浪费最强模型在简单任务上。
公司前端通用编码规范（从 11 个项目 + 飞书知识库抽取）。当用户开始编写/修改前端 TS/TSX/Vue/SCSS 代码，或者需要 code review / 检查规范一致性时，**必须**加载本 skill 作为硬性规则基础。
启动开发环境 + 调试。触发场景："看一下效果 / 跑起来看看 / 启动一下 / 打开看看 / 启动 dev / 跑 dev"。本 skill 读 profile.devServer 配置 → 校验前置 → 后台 spawn dev server → 等 ready → 拼带 token 的真实域名 URL → open 浏览器。同时含项目特定的"关键调试场景"片段（按 profile 加载）。