Menü
针对 PRD 需求中的不确定点逐条提问对齐。在 dev-flow 流程的第 2 步自动加载。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
读取并分析 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 过程中真正讨论过的术语。