Menu
针对 PRD 需求中的不确定点逐条提问对齐。在 dev-flow 流程的第 2 步自动加载。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
读取并分析 PRD 需求文档，提取要点和任务拆分。在 dev-flow 流程的第 1 步自动加载。
Uniplat 低代码平台编码规范速查。在 Uniplat 项目中进行任何开发任务时参考。
编码实现方法论：垂直切片 + TDD 核心循环。在 dev-flow 流程的第 5 步自动加载。
生成开发总结文档，记录交付物、依赖、设计要点。在 dev-flow 流程的第 8 步自动加载。
编码实现方法论：垂直切片，逐步推进。
在指定子项目目录下创建 Uniplat 数据模型脚手架（JSON 元数据 + Groovy 钩子文件）
| name | grill |
| description | 针对 PRD 需求中的不确定点逐条提问对齐。在 dev-flow 流程的第 2 步自动加载。 |
| version | 2.1.0 |
针对 PRD 需求中模糊、缺失、有歧义的部分，沿着决策树逐条向用户提问，直到所有关键不确定点都对齐。
不要按维度平铺提问，而是把 PRD 看作一棵决策树：
PRD
├── 决策 A：数据存在哪？
│ ├── 决策 A1：用新表还是复用旧表？
│ └── 决策 A2：字段如何设计？
├── 决策 B：接口怎么暴露？
│ ├── 决策 B1：新增接口还是扩展现有接口？
│ └── 决策 B2：参数格式？
└── 决策 C：UI 如何呈现？
└── 决策 C1：字段顺序和默认值？
遍历规则：
先推荐，再确认：每个问题先给出你的推荐答案和理由，再让用户确认或修改
我的建议：用新表 `user_preferences` 存储，理由是...
你觉得这样可以吗？还是有其他考虑？
一次只问一个问题：并行抛出多个问题会让用户混乱。问完一个，等回答，再问下一个。
先查答案来源，再问用户：能查到答案的问题不要问用户。
给出判断依据：推荐答案要说明为什么，不要只说"我建议 X"，要说"我建议 X，因为 Y"。
标记缺口：仅当 PRD 正文和截图/原型都未给出时才算真缺口——标为「缺口」、说明临时方案、继续推进。PRD 图里已标注的位置/文案不是缺口，直接按图定稿（与 tech-plan「图已定 vs 真待确认」一致）。
决策树遍历是主方法，以下维度帮助你在遍历中发现遗漏的决策节点：
| 维度 | 典型决策点 |
|---|---|
| 边界条件 | 空值怎么处理？最大/最小值？超限怎么办？ |
| 依赖关系 | 依赖哪个表/接口/其他任务？先后顺序？ |
| 存储结构 | 数据存在哪？新表还是复用？字段设计？ |
| UI 细节 | 字段折进已有列还是独立列？按钮/入口文案是否与 PRD 图逐字一致？入口挂哪个已有页签（是否误建新页签）？筛选放哪、与谁并列？字段顺序？默认值？交互方式？空状态？ |
| 异常处理 | 失败怎么提示？重试？回滚？ |
| 数据迁移 | 有存量数据吗？需要迁移吗？ |
| 性能 | 数据量多大？需要分页？有并发问题？ |
| 兼容性 | 需要兼容旧版本吗？接口变更？ |
使用 AskUserQuestion 工具：
问题：<具体决策问题>
选项 A：<你的推荐方案>（附理由）
选项 B：<备选方案 1>
选项 C：<备选方案 2>
1. 读完 PRD 后，画出决策树（列出所有决策节点和依赖关系）
↓
2. 从根节点开始（最不依赖其他决策的节点）
↓
3. 每个节点：先推荐 → 问用户 → 记录回答
↓
4. 回答可能揭示新节点 → 动态加入决策树
↓
5. 所有节点遍历完毕 → 检查是否有遗漏维度
↓
完成 → 进入步骤 3（问答记录）
在提问过程中，同步构建领域词汇表。这是 grill 的伴随纪律，不是独立步骤。
当用户使用的术语与已有定义冲突时，立即指出：
你说"取消订单"，但术语表里"取消"的定义是"用户主动撤销未支付的订单"。
你现在说的是"退款"（已支付订单的逆向操作），还是真正的"取消"？
当用户使用模糊或 overloaded 的术语时，追问精确含义：
你说"账户"——这里指的是 Customer（客户实体，包含基本信息）
还是 User（登录账户，包含凭证信息）？这两个在系统里是不同的东西。
当领域关系被讨论时，用具体场景验证边界：
如果订单已经发货，用户还能"取消"吗？
如果"取消"不行，那叫"退货"？退货和取消在系统里是同一个操作还是不同操作？
grill 完成后，将所有记录的术语输出到 <session_dir>/术语表.md：
# 术语表
> 记录日期：<日期>
> 范围：<本次涉及的任务列表>
## 术语定义
| 术语 | 定义 | 相关术语 | 备注 |
|------|------|---------|------|
| Customer | 客户实体，包含姓名、手机号等基本信息 | User, Order | 一个 Customer 可以有多个 User |
| User | 登录账户，包含账号、密码、状态 | Customer | 与 Customer 一对一关联 |
## 已解决歧义
- "账户"统一指 User（登录账户），Customer 不用"账户"称呼
- "取消"只用于未支付订单，已支付订单的逆向操作叫"退货"
## 待确认
- <暂时无法确定的术语定义>
注意：术语表不含实现细节（不写文件路径、字段名、表结构），只记录 grill 过程中真正讨论过的术语。