Back to Details

brainstorming

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Brainstorming Ideas Into Specs

将创意构思转化为规格说明

Overview

概述

Help turn ideas into fully formed designs or specs through natural collaborative dialogue.
Start by understanding the current project context in the project's root directory, then ask questions one at a time to refine the idea. Once you understand what you're creating, present the specs in small sections (200-300 words), checking after each section whether it looks right so far.
通过自然协作对话，帮助将创意转化为完整成型的设计或规格说明。
首先了解项目根目录下的当前项目背景，然后逐个提出问题来完善创意。当你明确要创建的内容后，将规格说明分成小章节（200-300字），每完成一个章节后都要确认目前的内容是否合适。

The Process

流程

Understanding the idea:
  • Check out the current project state first (files, docs, recent git commits) using subagent(s) to minimize LLM token usage
  • Ask questions one at a time to refine the idea
  • Prefer multiple choice questions when possible, but open-ended is fine too
  • Only one question per message - if a topic needs more exploration, break it into multiple questions
  • Only ask questions where the answer cannot be easily inferred from the project context, etc.
  • Focus on understanding: purpose, constraints, success criteria
Exploring approaches:
  • Propose 2-3 different approaches with trade-offs
  • Present options conversationally with your recommendation and reasoning
  • Lead with your recommended option and explain why
Presenting the specs:
  • Once you believe you understand what you're building, present the specs
  • Break it into sections of 200-300 words
  • Ask after each section whether it looks right so far
  • Cover all important aspects:
    • for coding projects: architecture, components, data flow, performance, security, multithreading / async processing, error handling, testing
    • for non-coding projects: confirm the list of aspects to cover with the user
  • Be ready to go back and clarify if something doesn't make sense
理解创意：
  • 首先借助subagent查看当前项目状态（文件、文档、最新git提交记录），以减少LLM的token消耗
  • 逐个提出问题来完善创意
  • 尽可能优先使用选择题，但开放式问题也可
  • 每条消息仅提出一个问题——若某个话题需要深入探究，拆分成多个问题
  • 仅提出无法从项目背景等信息中轻易推断出答案的问题
  • 重点理解：目的、约束条件、成功标准
探索实现方案：
  • 提出2-3种不同的实现方案，并说明各自的利弊
  • 以对话形式呈现选项，同时给出你的推荐及理由
  • 优先展示你推荐的选项并解释原因
呈现规格说明：
  • 当你明确要构建的内容后，开始呈现规格说明
  • 将内容拆分成200-300字的章节
  • 每完成一个章节后，询问用户当前内容是否合适
  • 覆盖所有重要方面：
    • 针对编码项目：架构、组件、数据流、性能、安全、多线程/异步处理、错误处理、测试
    • 针对非编码项目：与用户确认需要覆盖的内容清单
  • 若内容存在不合理之处，随时准备回溯并澄清

After the Specs

规格说明完成后

Documentation:
  • Write the validated specs to 
    docs/YYYY-MM-DD-<topic>-specs.md
Detailed Execution Plan (if continuing):
  • Ask: "Ready to continue with a detailed task breakdown?"
  • Use the task-breakdown skill to create detailed task breakdown
文档编写：
  • 将经过验证的规格说明写入
    docs/YYYY-MM-DD-<topic>-specs.md
详细执行计划（若继续推进）：
  • 询问用户：“是否要继续制定详细的任务分解计划？”
  • 使用task-breakdown skill创建详细的任务分解

Key Principles

核心原则

  • One question at a time - Don't overwhelm with multiple questions
  • Multiple choice preferred - Easier to answer than open-ended when possible
  • YAGNI ruthlessly - Remove unnecessary features from all designs
  • Explore alternatives - Always propose 2-3 approaches before settling
  • Incremental validation - Present specs in sections, validate each
  • Be flexible - Go back and clarify when something doesn't make sense
  • AskUserQuestion tool - must use this tool to ask questions to the user
  • 一次一个问题——不要用多个问题让用户应接不暇
  • 优先选择题——相较于开放式问题，选择题更易作答
  • 严格遵循YAGNI原则——从所有设计中移除不必要的功能
  • 探索替代方案——在确定方案前，始终提出2-3种备选方案
  • 增量式验证——分章节呈现规格说明，逐一验证
  • 保持灵活——若内容存在不合理之处，回溯并澄清
  • 必须使用AskUserQuestion工具——向用户提问时必须使用该工具