pbs-exploration-brainstorming

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Exploration Brainstorming

探索性头脑风暴

Overview

概述

Guide structured brainstorming sessions for an ENTIRE PROJECT to define the problem, solution, scope, risks, and open questions. The output is a synthesis document — not the conversation itself.

Core principle: The value is NOT the conversation — it's the synthesis document produced at the end. Conversations are long and messy. The synthesis extracts only what survived.

Announce at start: "I'm using the pbs-exploration-brainstorming skill to explore this project idea."

为整个项目引导结构化的头脑风暴会议，明确问题、解决方案、范围、风险和待解决问题。最终产出是一份总结文档，而非对话记录本身。

核心理念： 价值不在于对话过程，而在于最终产出的总结文档。对话通常冗长杂乱，总结只会提炼经过验证的有效信息。

会议开场声明： "我正在使用pbs-exploration-brainstorming技能来探索这个项目想法。"

When to Use

适用场景

Starting a new project from scratch — the idea is vague and needs structure
Exploring a project concept before making ANY technical decisions
NOT for features in existing codebases — use codebase-familiarization + feature-planning instead

从零启动新项目，想法还很模糊，需要梳理结构
在做出任何技术决策前探索项目概念
不适用现有代码库的功能迭代——这类场景请使用codebase-familiarization + feature-planning

When NOT to Use

不适用场景

You already have a clear Project Brief → skip to generating-definitions
You're adding a feature to an existing codebase → use codebase-familiarization first, then this skill's Lightweight Mode if the feature needs conceptual exploration
You're making technical decisions (stack, APIs) → that's exploration-discovery, not this

你已经有清晰的项目说明→直接跳转到generating-definitions
你要给现有代码库新增功能→先使用codebase-familiarization，如果功能需要概念探索可以使用本技能的轻量模式
你正在做技术决策（技术栈、API选型）→这属于exploration-discovery的范畴，不适用本技能

Input

输入要求

Required: A project idea or concept (can be vague or well-formed)
Optional: Feature request or ticket (if using Lightweight Mode for an existing codebase)

No documents required — this is the entry point of the framework.

必填： 项目想法或概念（可以是模糊的也可以是成型的）
可选： 功能需求或工单（如果是为现有代码库使用轻量模式）

无需提前准备任何文档——本流程是整个框架的入口点。

The Process

执行流程

Step 1: Understand the Starting Point

步骤1：明确起始状态

Ask the human to describe their idea. Then assess:

How clear is the problem? (vague / somewhat clear / well-defined)
How clear is the solution? (no idea / rough direction / specific vision)
Is the scope bounded? (open-ended / loosely bounded / well-scoped)

This determines how deep to go in each block.

Framework language: If

AGENTS.md

does not already have a

framework_language

field, ask the human:

"In what language should the framework documents (.pbs-framework/) be written? (e.g., English, Spanish)"

This applies ONLY to

.pbs-framework/

documents (syntheses, specs, roadmaps, closure reports). It does NOT apply to code, READMEs, or project documentation — those follow whatever conventions the project uses.

Record the answer to include in the synthesis so that

pbs-generating-definitions

can set it in AGENTS.md.

请相关人员描述他们的想法，然后评估以下维度：

问题的清晰程度？（模糊/基本清晰/明确定义）
解决方案的清晰程度？（完全没有想法/大致方向/明确愿景）
范围是否有边界？（完全开放/松散边界/范围明确）

以上评估会决定每个模块的探索深度。

框架语言： 如果

AGENTS.md

中还没有

framework_language

字段，询问相关人员：

"框架文档（.pbs-framework/目录下）应该使用什么语言编写？（例如：中文、英文）"

该设置仅适用于

.pbs-framework/

下的文档（总结、规范、路线图、结项报告），不适用于代码、README或项目自有文档——这些文档遵循项目本身的约定即可。

记录回答并纳入总结文档，方便

pbs-generating-definitions

将其写入AGENTS.md。

Step 2: Explore the 5 Blocks

步骤2：探索5个核心模块

Guide the human through 5 thematic blocks. Ask questions one at a time — never dump all questions at once. Propose 2-3 approaches when relevant to help the human decide.

For the detailed questionnaire per block, see questionnaire-reference.md.

Block 1: The Problem

What concrete problem are you solving? (2-3 sentences)
Who has this problem? (specific person, not "everyone")
How do they solve it today? What's frustrating about current solutions?
Why does this problem matter?

Block 2: Proposed Solution

What's your solution in one sentence?
What's the simplest happy path? (minimum viable flow)
What makes this different from what exists?
What assumptions must be true for this to work?

Block 3: Scope and Limits

Is this a POC (technical feasibility) or MVP (user validation)?
What's IN the first cut? What's explicitly OUT?
What's the simplest proof of success?
How much time are you willing to invest?

Block 4: Users and Context

Who is the primary user? (role, technical level, motivation)
In what context do they use this? (desktop, mobile, CLI, automated)
How often? What output do they expect?

Block 5: Risks and Open Questions

What could go wrong? (technically, conceptually, dependencies)
What don't you know yet that you NEED to know?
Are there critical external dependencies?
What's the plan B if the core idea doesn't work?

引导相关人员完成5个主题模块的探索。每次只提一个问题，不要一次性抛出所有问题。相关的时候可以给出2-3种方案供人员参考决策。

每个模块的详细问卷请查看questionnaire-reference.md。

模块1：问题

你正在解决的具体问题是什么？（2-3句话说明）
谁存在这个问题？（具体人群，不要说"所有人"）
他们目前是怎么解决这个问题的？现有解决方案的痛点是什么？
为什么这个问题值得解决？

模块2：提议的解决方案

用一句话说明你的解决方案是什么？
最简单的核心使用流程是什么？（最小可行流程）
这个方案和现有产品的差异是什么？
方案可行的前提假设是什么？

模块3：范围与边界

这是POC（技术可行性验证）还是MVP（用户价值验证）？
第一版的范围包含什么？明确不包含什么？
最简单的成功证明是什么？
你愿意投入多少时间？

模块4：用户与使用场景

核心用户是谁？（角色、技术水平、使用动机）
他们会在什么场景下使用？（桌面端、移动端、CLI、自动化场景）
使用频率如何？他们期望的产出是什么？

模块5：风险与待解决问题

可能出现什么问题？（技术层面、概念层面、依赖层面）
有哪些你还不知道但必须明确的信息？
是否存在关键的外部依赖？
如果核心想法行不通，备选方案是什么？

Prompting Techniques

提问技巧

Use these during the conversation to push beyond surface-level thinking:

Constraint-based prompting: Add limits to force creativity. "5 ideas that a solo dev can build in 2 weeks, no backend, offline-first"
Unexpected keyword injection: Introduce concepts from other domains. "What if we applied the concept of 'medical triage' to prioritizing these alerts?"
Perspective multiplication: "How would a Netflix engineer solve this? A 3-person startup? A student?"
"What if" framework: "What if this had to work without internet? What if users could only use it 5 minutes a day?"
Devil's advocate: "Play devil's advocate — what would make this idea fail completely?"

对话过程中可以使用以下技巧，推动大家跳出表层思考：

约束式提问： 增加限制条件激发创造力。"列出5个单人开发两周就能完成、不需要后端、优先离线可用的方案"
跨领域关键词注入： 引入其他领域的概念。"如果我们把'医疗分诊'的概念用到这些告警的优先级排序上会怎么样？"
多视角发散： "Netflix的工程师会怎么解决这个问题？3人规模的创业公司呢？学生呢？"
"假设"框架： "如果这个产品必须在无网络的情况下运行怎么办？如果用户每天只能用5分钟怎么办？"
唱反调： "来挑挑刺——什么情况会让这个想法彻底失败？"

Step 3: Check Readiness

步骤3：检查就绪状态

Step 4: Generate Synthesis

步骤4：生成总结文档

When all readiness signals are met, generate the brainstorming synthesis document.

Output location:

.pbs-framework/exploration/brainstorming-synthesis.md

For the full synthesis template, see questionnaire-reference.md section "Synthesis Template".

The synthesis MUST include:

The Problem — description, who has it, current solutions
Proposed Solution — one-sentence description, happy path, differentiator
Scope — POC/MVP, included/excluded, success criterion
Key Assumptions — what must be true, validation status
Identified Risks — with impact and mitigation
Open Questions for Discovery — technical questions only
Explored and Discarded Ideas — brief record to avoid re-exploring dead ends
Framework Language — the chosen language for
```
.pbs-framework/
```
documents

<HARD-GATE> The human MUST approve the synthesis before proceeding to discovery. If the human finds gaps or disagreements, iterate until the synthesis accurately captures the idea as understood by the human — not as interpreted by the agent. </HARD-GATE>

所有就绪条件都满足后，生成头脑风暴总结文档。

输出位置：

.pbs-framework/exploration/brainstorming-synthesis.md

完整的总结模板请查看questionnaire-reference.md的"总结模板"部分。

总结必须包含以下内容：

问题——描述、受众、现有解决方案
提议的解决方案——一句话描述、核心流程、差异化优势
范围——POC/MVP、包含/排除内容、成功标准
核心假设——前提条件、验证状态
识别到的风险——附带影响和缓解方案
待调研的问题——仅技术问题
探索过但放弃的想法——简单记录避免重复走弯路
框架语言——
```
.pbs-framework/
```
文档选定的编写语言

<硬性关卡> 进入调研阶段前必须让相关人员确认总结文档。如果人员发现有遗漏或不符的地方，反复迭代直到总结准确还原了相关人员对想法的理解，而不是Agent的解读。 </硬性关卡>

Lightweight Mode (Existing Codebase Features)

轻量模式（现有代码库的功能迭代）

When brainstorming a feature for an existing codebase (not a new project):

Use only Blocks 1-3 (Problem, Solution, Scope)
Output a
```
feature-brief.md
```
instead of a full synthesis
Skip Blocks 4-5 (users and risks are already known from the codebase)
Transition to feature-planning instead of exploration-discovery

当为现有代码库 brainstorm 新功能（不是新项目）时：

仅使用模块1-3（问题、解决方案、范围）
输出
```
feature-brief.md
```
而非完整的总结文档
跳过模块4-5（用户和风险已经从现有代码库信息中明确）
后续流转到feature-planning，而非exploration-discovery

Session Structure (Suggested)

会议结构（建议）

Session 1: Problem + Solution (Blocks 1-2)
  Duration: 1-2 hours
  Technique: Ask the AI to question YOU instead of you asking it

Session 2: Scope + Users (Blocks 3-4)
  Duration: 1-2 hours
  Technique: Perspective multiplication — explore from different user types

Session 3: Risks + Synthesis (Block 5 + document generation)
  Duration: 1-2 hours
  Technique: Devil's advocate — try to destroy the idea

Sessions can be combined or split further depending on complexity.

会议1：问题 + 解决方案（模块1-2）
  时长：1-2小时
  技巧：让AI向你提问，而不是你问AI

会议2：范围 + 用户（模块3-4）
  时长：1-2小时
  技巧：多视角发散——从不同用户类型的角度探索

会议3：风险 + 总结（模块5 + 文档生成）
  时长：1-2小时
  技巧：唱反调——尝试推翻这个想法

可以根据项目复杂度合并或拆分会议。

Common Mistakes

常见错误

Dumping all questions at once — ask one at a time. Let the human think and respond before moving on.
Accepting the first answer without probing — use devil's advocate and "what if" to push past surface-level thinking.
Jumping to technical decisions — "What framework?" belongs in discovery. Here we define WHAT, not HOW.
Synthesis reads like a transcript — extract conclusions only. The synthesis is a reference document, not a conversation log.

一次性抛出所有问题——每次只问一个，让相关人员思考回应后再继续下一个。
不深究就接受第一个答案——使用唱反调和"假设"技巧推动大家跳出表层思考。
过早跳到技术决策——"用什么框架？"属于调研阶段的问题，这个阶段我们只定义"做什么"，不讨论"怎么做"。
总结写得像对话记录——只提炼结论，总结是参考文档，不是对话日志。

Red Flags

危险信号

Jumping to technical decisions → "What framework should I use?" belongs in discovery, not here.
Accepting the first idea without questioning it → If you end with the same idea you started with, you didn't brainstorm.
All questions answered in one session → For a real project, this usually means the exploration was shallow.
No open questions for discovery → Every project has technical unknowns. If you found none, you didn't look hard enough.
Synthesis that reads like a conversation transcript → Extract conclusions only.

过早跳到技术决策→"我该用什么框架？"属于调研阶段的问题，不应该出现在这个阶段。
不质疑就接受最初的想法→如果结束时的想法和开始时完全一样，说明你根本没做头脑风暴。
一次会议就回答完所有问题→对于真实项目来说，这通常意味着探索不够深入。
没有待调研的技术问题→每个项目都有技术未知点，如果没找到，说明你找得不够仔细。
总结写得像对话记录→只提炼结论即可。

Common Rationalizations

常见借口

Excuse	Reality
"The idea is already clear, skip brainstorming"	If it's clear, the synthesis will be quick. Still write it.
"I already know the stack"	Stack belongs in discovery. Here we define WHAT, not HOW.
"Risks are obvious, no need to list them"	Obvious risks are the ones that get ignored. List them.
"The scope is the whole app"	That's not a scope. Define what's IN and what's OUT.
"Let's just start coding and figure it out"	That's vibe coding. This framework exists to prevent it.

借口	现实
"想法已经很清楚了，跳过头脑风暴吧"	如果真的清楚，写总结会很快，还是要写。
"我已经确定技术栈了"	技术栈属于调研阶段的内容，这个阶段我们定义"做什么"，不是"怎么做"。
"风险都很明显，不用列出来"	明显的风险最容易被忽略，一定要列出来。
"范围就是整个应用"	这不叫范围，明确定义包含什么、不包含什么。
"我们先写代码，边写边想"	这是凭感觉写代码，这个框架就是为了避免这种情况。

Integration

流程集成

Entry point: This is the first skill in the framework — no prerequisites.

Calls next:

pbs-exploration-discovery — after human approves the synthesis (standard flow)
pbs-feature-planning — after lightweight brainstorming for existing codebases

入口点： 这是整个框架的第一个技能，无前置要求。

后续流转：

pbs-exploration-discovery——相关人员确认总结文档后（标准流程）
pbs-feature-planning——现有代码库使用轻量模式完成头脑风暴后