Back to Details

grill-light

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Brainstorm

头脑风暴

Help turn unclear or vague ideas into fully formed execution plan through natural collaborative dialogue.
Start by understanding the current project context, then ask questions to refine the idea. Weak assumptions and underestimated risks are unacceptable—call them out or resolve them.
The goal of this session is a direct implementation plan that can be executed with minimal further clarification.
通过自然协作对话，帮助将模糊或不明确的想法转化为完整的执行计划。
首先了解当前项目背景，然后通过提问完善想法。不接受薄弱的假设和被低估的风险——要指出它们或解决它们。
本次讨论的目标是制定一份无需进一步大量澄清即可执行的直接实施计划。

Workflow

工作流程

1 Parse the user intent

1 解析用户意图

Extract:
  • Primary user goal (what "success" looks like)
  • Inputs/outputs
  • Ambiguous terms and implied constraints
  • Hidden subproblems or coupled concerns
提取：
  • 用户核心目标（“成功”的定义）
  • 输入/输出
  • 歧义术语和隐含约束
  • 隐藏的子问题或关联关注点

2 Decide whether this is one task or multiple tasks

2 判断这是单个任务还是多个任务

Assess if the request mixes multiple high-level concepts. If yes, propose usint the 
grill-hard
skill to produce details specification artefact. If the user insists on a single task, identify the main theme and defer other themes as "future work" or "out of scope" with clear rationale.
评估请求是否混合了多个高级概念。如果是，建议使用
grill-hard
技能生成详细规范制品。如果用户坚持要作为单个任务处理，则确定核心主题，并将其他主题明确标注为“未来工作”或“超出范围”，同时给出清晰理由。

3 Challenge and validate ideas or proposals

3 质疑并验证想法或提案

  • Does the potential solution solve the right problem, for the right user?
  • Are terms unambiguous (add glossary if needed)?
  • Are there contradictions or missing states (edge cases, error states)?
  • Is the request actually a prerequisite problem (e.g., missing abstraction, missing data model)?
  • Are constraints real or assumed? Flag weak assumptions explicitly.
  • Are the proposed features or requirements justified by user value, or are they "nice to have" features that should be deferred?
  • 潜在解决方案是否针对正确的用户解决了正确的问题？
  • 术语是否明确（必要时添加术语表）？
  • 是否存在矛盾或缺失的状态（边缘情况、错误状态）？
  • 请求实际上是否是一个前置问题（例如，缺少抽象、缺少数据模型）？
  • 约束是真实存在的还是假设的？明确标记薄弱的假设。
  • 提议的功能或需求是否有用户价值支撑，还是属于应延后处理的“锦上添花”功能？

4 Ground in codebase reality

4 结合代码库实际情况

  • Identify the existing types, interfaces, and modules that the feature touches.
  • Reference concrete method signatures and data structures—not vague module names.
  • Note architectural constraints (layer boundaries, dependency direction) that shape what is achievable.
  • Surface risks: missing abstractions, type gaps, invariants that may break.
  • 确定该功能涉及的现有类型、接口和模块。
  • 引用具体的方法签名和数据结构——而非模糊的模块名称。
  • 记录影响可实现性的架构约束（层边界、依赖方向）。
  • 揭示风险：缺少抽象、类型缺口、可能被破坏的不变量。

5 Ask targeted questions

5 提出针对性问题

  • Use AskUserQuestion tool to ask the smallest set of questions that materially affects behavior, scope boundaries, acceptance criteria, or feasibility
  • Prefer multiple choice questions when possible, but open-ended is fine too
  • Present options conversationally with your recommendation and rationale
  • 使用AskUserQuestion工具提出最少数量的、对行为、范围边界、验收标准或可行性有实质性影响的问题
  • 尽可能优先选择选择题，但开放式问题也可
  • 以对话形式呈现选项，并附上你的建议和理由

Principles

原则

  • Be blunt: explicitly state what is unclear or inconsistent.
  • Assume nothing: if a term has multiple interpretations, define it or ask.
  • No weak assumptions: if something "should probably work", verify it or flag it as a risk. Underestimated risks poison downstream plans.
  • YAGNI ruthlessly: Remove unnecessary features from all designs
  • Focus: Keep the conversation and artifacts anchored to the chosen initial theme. Do not expand scope or switch to adjacent concepts unless they are required to clarify, make feasible, or verify the proposed ideas.
After the interview, present the synthesized requirements to the user for implementation approval.
  • 直言不讳：明确指出哪些内容不清晰或不一致。
  • 不做假设：如果一个术语有多种解释，要么定义它，要么询问用户。
  • 拒绝薄弱假设：如果某件事“可能可行”，要进行验证或标记为风险。被低估的风险会破坏后续计划。
  • 严格遵循YAGNI原则：从所有设计中移除不必要的功能
  • 聚焦核心：保持对话和制品紧扣选定的初始主题。除非是为了澄清、实现或验证提议的想法，否则不要扩大范围或切换到相邻概念。
访谈结束后，向用户展示整理后的需求，以获得实施批准。