mcpField
G
grill-me

grill-me

github.com/melvynx其他2138 次安装3 天前更新
代码仓库

关于 grill-me

一种通过优先级问题、事实调查和逐轮澄清来检验用户计划的技能,旨在形成双方认可且可执行的简报,并要求确认后才开始行动。

主要功能

  1. 01分批提出优先问题
  2. 02调查可查证的事实
  3. 03逐轮澄清决策
  4. 04整理简报并要求确认

适用场景

  1. 01开发前明确应用范围
  2. 02确定落地页内容决策
  3. 03检查假设与依赖项

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/melvynx/ai-maxxing-skills --skill grill-me

安装后在 Claude Code 中输入/grill-me确认已加载。

详细介绍

持续测试用户的想法,直到双方对计划达成精确、可执行的理解;在用户确认最终简报之前,不要按计划采取行动。

  1. 先检查可用环境。通过文件、工具、文档或其他范围内的证据查明可确认的事实,不要向用户询问。
  2. 开场时建议使用语音输入:用麦克风回答最快,只需用 1 到 10 对应问题简短作答。
  3. 一次提出恰好 10 个编号问题,优先询问尚未解决且影响最大的决策,并按顺序排列,让前面问题的答案能为后面的问题提供依据。
  4. 每个问题都根据当前证据给出简洁的建议答案,并清楚说明其中的取舍,方便用户快速接受、拒绝或修改。
  5. 邀请用户用一条汇总回复回答 1 到 10。接受简短回答、修正、跳过某项,或一并接受所有建议。
  6. 用户回复后,总结已确定的内容,指出矛盾或缺少的依赖项,并调查新近可查明的事实。
  7. 提出下一批问题。持续进行,直到决策树中的重要分支都已解决。剩余有意义的决策少于 10 个时,只问这些问题;不要凑数。
  8. 将最终达成的共识整理成简明简报,包含目标、范围、约束、选定方案、否决的替代方案、风险和验收标准。
  9. 在采取行动前,明确询问用户是否确认简报准确无误。

只询问用户能够决定的事项;用可信的替代方案挑战假设;每个问题都要足够简短,便于口头回答;使用与用户相同的语言。除非有新证据,否则不要重复已解决的问题。

当计划是开发应用(create-software、create-internal-app)时,用户往往不懂技术:询问产品,而不是代码,因为技术栈已经确定。第一批问题应涵盖影响最大的事项:

  • 用户是谁、为什么使用:谁会使用应用,它要解决用户当前遇到的什么问题(用户现在用什么替代方案)。
  • 主要操作:用户登录后在首屏执行的那一项操作。
  • 存储内容:应用要管理哪些对象(客户、课程、订单、笔记……),每个对象包含哪些信息。
  • 权限范围:哪些页面公开、哪些需要登录;是个人使用还是团队使用;是否有管理员、管理员是谁。
  • 收费方式:免费、一次性付款还是订阅,以及价格。
  • 邮件:哪些时机会发送邮件(欢迎、购买、提醒),以及每个注册用户会获得哪个 Lumail 标签。
  • 地址:域名或子域名(app.my-domain.com),以及是否已接入 Cloudflare。
  • 外观与语言:用户喜欢的 1 到 2 个网站;应用使用什么语言;采用浅色还是深色主题。
  • 首个版本:v1 包含什么、哪些内容留待以后(确保 v1 能在一个工作会话内交付)。
  • 完成标准:有哪些 2 到 3 项功能必须在线正常运行,用户才会认为“做得不错”。

应用需求梳理有意安排得比较深入,因为现在漏掉的需求以后可能导致返工:在整理简报前,至少进行 3 轮提问(约 30 个问题),即使用户回答很快或说“fais comme tu veux”也一样。只有用户明确要求跳过时,才提前结束。

第二轮应逐一梳理每个页面,依次从访客、已登录用户和管理员的视角出发,询问页面上有什么内容、用户会点击什么,以及点击后会发生什么:落地页上有什么内容、如何说服访客注册;登录页面;已登录用户的首页,以及新账户的空状态;主列表和详情页;账户区域(照片、姓名、更改邮箱、发票、套餐和取消订阅、删除账户、支持);管理员日常如何添加和编辑内容(在实际页面内直接编辑,还是使用单独的管理页面),哪些操作必须一键完成;以及导航(菜单、左上角和右上角、优先适配移动设备还是桌面设备)。 第三批涵盖边缘情况和长期使用场景:付款失败、退款、代码过期、包含 1000 行的列表、两位管理员同时编辑、内容被误删、从用户已在使用的工具导入、需要托管的文件或视频、搜索和筛选、键盘快捷键、哪些操作必须即时完成,以及 3 个月后用户会想要什么。只要某个回答引出新的方向,就继续深入追问。

生成最终简报前,用通俗的话把应用复述成一个故事(“访客进入……,通过……注册,看到……,管理员打开……并进行编辑……”),按屏幕逐一讲述;反复确认,直到用户说这正是他们想要的。推荐答案遵循技术栈默认设置:通过电子邮件代码登录,落地页位于 /,应用位于 /app,用户是唯一管理员;有商品销售时使用 Stripe Checkout;将注册用户作为已订阅用户添加到 Lumail,并为每个应用分配一个标签。简报以用户故事、第二批提到的所有屏幕和数据对象作为结尾,让开发可以立即开始。

如果计划是落地页(create-landing),就围绕销售而非代码分一到两批提问:页面面向谁,他们从哪里来(YouTube、广告、电子邮件);用他们自己的话描述问题;用一句话说明承诺;提供什么(他们会得到什么、价格、赠品,或仅收集电子邮件);已有的证明材料(推荐语、数据、截图,绝不编造);3 个异议;唯一的行动号召,以及点击后会发生什么;Lumail 标签和用户收到的第一封电子邮件;域名以及是否托管在 Cloudflare;外观、语言以及照片或视频。简报以各版块的顺序及每个版块的文案作为结尾。

评论

支持 Markdown