project-brainstorming

适用场景

• 在需求不明确时启动新项目
• 在编写规格说明前探索问题领域
• 需要系统地比较多种方案
• 验证项目的可行性和范围
• 为利益相关者记录决策依据
• 需要明确要解决的核心问题

不适用场景

• 已有需求和规格说明（改用 Skill(attune:project-planning)）
• 优化现有规格说明（改用 Skill(attune:project-specification)）
• 项目范围已明确定义（直接跳转到 /attune:project-init）
• 项目中途调整方向（使用 Skill(attune:war-room) 制定战略决策）

集成

与 superpowers 配合：

• 委托 Skill(superpowers:brainstorming) 运用苏格拉底式提问法
• 补充特定于项目的模式
• 使用项目头脑风暴模板

不使用 superpowers 时：

• 独立的提问框架
• 以项目为中心的构思模式
• 结构化输出模板

War Room 集成（必需）：

• 第 3 阶段（方案生成）结束后，自动调用 Skill(attune:war-room)
• 将所有头脑风暴背景信息传递给 War Room，供专家研讨
• War Room 提供多 LLM 压力测试和综合分析
• 仅在 Type 2 决策（RS ≤ 0.40）且获得用户明确确认时跳过

头脑风暴框架

阶段 1：问题定义

苏格拉底式提问：

1. 你要解决什么问题？
2. 谁会遇到这个问题？
3. 为什么现在值得解决这个问题？
4. 如果这个问题得不到解决，会发生什么？
5. 目前尝试过哪些解决方案？
6. 谁会阅读这个项目的产出？他们已经了解什么？请指出一个足够具体的角色，能让人明确知道担任该角色的人是谁。

问题 6 用于确定受众层级，项目生成的每份文档都会沿用该层级：newcomer、practitioner、expert，或一行描述的 persona。应在此处提问，而不是等到起草时再问；否则为了让起草继续进行，答案可能会靠猜测得出。层级表和后续问题：scribe:slop-detector 模块 audience-targeting.md。

输出：在 docs/project-brief.md 中记录问题陈述

模板：

## Problem Statement

**Who**: [Target users/stakeholders]
**What**: [The problem they face]
**Where**: [Context where problem occurs]
**When**: [Frequency/timing of problem]
**Why**: [Impact of the problem]
**Current State**: [Existing solutions and limitations]
**Doc audience**: [newcomer | practitioner | expert | persona: <one line>]

**验证：**运行命令并添加 --help 标志，以确认命令可用。

阶段 2：约束发现

问题：

1. 有哪些不可妥协的技术约束？
2. 有哪些资源约束（时间、预算、团队）？
3. 需要哪些集成点？
4. 适用哪些合规或监管要求？
5. 成功标准和失败模式是什么？

输出：约束矩阵

模板：

## Constraints

### Technical
- [Constraint 1 with rationale]
- [Constraint 2 with rationale]

### Resources
- **Timeline**: [Duration with milestones]
- **Team**: [Size and skills]
- **Budget**: [If applicable]

### Integration
- [Required system 1]
- [Required system 2]

### Compliance
- [Requirement 1]
- [Requirement 2]

### Success Criteria
- [ ] [Measurable criterion 1]
- [ ] [Measurable criterion 2]

**验证：**运行命令并添加 --help 标志，以确认命令可用。

阶段 3：方案生成

方法：生成 3-5 种不同的方案

每种方案需包含：

• 清晰的描述（1-2 句话）
• 技术栈
• 优点（3-5 点）
• 缺点（3-5 点）
• 风险（2-3 点）
• 预估工作量
• 权衡

模板：

## Approach [N]: [Name]

**Description**: [Clear 1-2 sentence description]

**Stack**: [Technologies and tools]

**Pros**:
- [Advantage 1]
- [Advantage 2]
- [Advantage 3]

**Cons**:
- [Disadvantage 1]
- [Disadvantage 2]
- [Disadvantage 3]

**Risks**:
- [Risk 1 with likelihood]
- [Risk 2 with likelihood]

**Effort**: [S/M/L/XL or time estimate]

**Trade-offs**:
- [Trade-off 1 with mitigation]
- [Trade-off 2 with mitigation]

**验证：**运行命令并添加 --help 标志，以确认命令可用。

面向隔离的设计：

生成方案时，请使用以下两项隔离测试评估每种方案：

1. 理解测试：不阅读内部实现，是否也能理解每个单元的作用？如果必须查看实现细节才能理解某个单元的用途，说明边界划分有误。
2. 变更测试：修改某个单元的内部实现，是否会导致其使用方出问题？如果修改实现细节会迫使其他地方也要改动，说明接口泄漏了。

文件大小作为设计信号：超过 500 行（Python/Go）或 300 行（JavaScript/TypeScript）的文件，往往表明某个单元承担了过多职责。这是设计异味，不只是风格问题。指出大型文件时，应建议拆分具体职责（例如：“将验证逻辑提取到单独的模块，以提升可测试性”）。

**验证：**运行命令并添加 --help 标志，以确认命令可用。

阶段 3.5：战情室审议（必需）

自动触发：生成方案后，必须调用 Skill(attune:war-room) 进行专家审议

调用战情室时：

• 所有头脑风暴上下文（问题、约束、方案）都会自动传递给战情室
• 专家小组会审查、质疑并检验每个方案
• 开展可逆性评估
• 通过多大模型审议识别盲点
• 最高指挥官给出综合结论及理由

命令：

# Automatically invoked from brainstorm - DO NOT SKIP
/attune:war-room --from-brainstorm

战情室输出：

• 可逆性评分（RS）和决策类型
• 针对每个方案的红队质疑
• 对选定方案进行事前验尸分析
• 最高指挥官决策文档
• 实施指令和关注点

跳过条件（仅当以下条件全部满足时才跳过战情室）：

• RS ≤ 0.40（Type 2 决策——显然可逆）
• 只有一个明显的方案，且没有实质性权衡
• 复杂度低，且有完善的文档记录的模式可循
• 向用户展示 RS 评估后，用户明确拒绝

战情室完成后，才能进入阶段 4

阶段 4：方案比较

比较矩阵：

标准	方案 1	方案 2	方案 3	方案 4
技术契合度	🟢 高	🟡 中	🟡 中	🔴 低
资源效率	🟡 中	🟢 高	🔴 低	🟡 中
见效时间	🟢 快	🟡 中	🔴 慢	🟢 快
风险等级	🟡 中	🟢 低	🔴 高	🟡 中
可维护性	🟢 高	🟡 中	🟢 高	🔴 低

评分：🟢 = 良好，🟡 = 可接受，🔴 = 存在隐忧

阶段 5：决策与理由

选择标准：

1. 是否符合约束（必须全部满足）
2. 风险与收益的平衡
3. 团队能力和经验
4. 见效时间
5. 长期可维护性

模板：

## Selected Approach: [Approach Name] ⭐

### Rationale
[2-3 paragraphs explaining why this approach was selected]

Key decision factors:
- [Factor 1]
- [Factor 2]
- [Factor 3]

### Trade-offs Accepted
- **Trade-off 1**: [Description] → Mitigation: [Strategy]
- **Trade-off 2**: [Description] → Mitigation: [Strategy]

### Rejected Approaches
- **Approach X**: Rejected because [reason]
- **Approach Y**: Rejected because [reason]

验证： 使用 --help 标志运行命令，以验证是否可用。

阶段 5.5：记录权衡（决策日志）

现在将阶段 5 的选择记录到 docs/tradeoffs.md，趁此时推理过程还清晰。这条记录将留存至本次会话结束之后：包括决策、权衡过的备选方案，以及放弃了什么。起草并确认：

• 如果已安装 leyline，调用 Skill(leyline:decision-journal) 并按其说明追加一条权衡记录。阶段 5 的字段直接对应如下：Selected Approach 对应 decision，理由对应一条 Y 陈述，Trade-offs Accepted 对应 consequences_negative，Rejected Approaches 对应 options。将 phase 设为 brainstorm。展示起草的记录；经用户确认后追加（状态初始为 proposed）。
• 备用方案（未安装 leyline）：手动使用文件中的 ENTRY TEMPLATE 向 docs/tradeoffs.md 追加一条记录；分配下一个 TR-NNN ID，并添加一行活动索引。

仅当确实只有一个明显的方案且没有实质性权衡时才跳过（与跳过战情室的条件相同）。

输出：项目简报

最终输出保存到 docs/project-brief.md：

# [Project Name] - Project Brief

**Date**: [YYYY-MM-DD]
**Author**: [Name]
**Status**: Draft | Approved

## Problem Statement
[From Phase 1]

## Goals
1. [Primary goal]
2. [Secondary goal]
3. [Tertiary goal]

## Constraints
[From Phase 2]

## Approach Comparison
[From Phase 3 & 4]

## War Room Decision
[From Phase 3.5 - includes RS assessment, Red Team challenges, premortem]

## Selected Approach
[From Phase 5, informed by War Room synthesis]

## Next Steps
1. `/attune:specify` - Create detailed specification
2. `/attune:blueprint` - Plan architecture and tasks
3. `/attune:project-init` - Initialize project structure

验证： 使用 --help 标志运行命令，以验证是否可用。

提问模式

苏格拉底式方法

澄清：

• “你所说的 [术语] 是什么意思？”
• “能举个例子吗？”
• “X 和 Y 有什么区别？”

探究假设：

• “你对 [方面] 有什么假设？”
• “你为什么认为这个假设成立？”
• “如果这个假设是错的呢？”

探究推理：

• “你为什么认为这个方案最好？”
• “有什么证据支持这一点？”
• “还有其他解释吗？”

质疑观点：

• “[利益相关方] 会怎么看这件事？”
• “有哪些反驳观点？”
• “这可能会如何失败？”

探究影响：

• “如果我们选择这个方案，会发生什么？”
• “长期后果是什么？”
• “这会让我们承担什么义务？”

基于约束的思考

必须具备（不可妥协）：

• 成功的绝对必要条件是什么？
• 哪些约束无法改变？

应该具备（重要）：

• 哪些因素会显著提升成功率？
• 哪些偏好最重要？

可以具备（锦上添花）：

• 哪些因素有益但并非关键？
• 必要时哪些内容可以推迟或舍弃？

不会具备（明确排除）：

• 我们明确不会做什么？
• 哪些范围边界可以防止需求蔓延？

需要指出的危险信号

在头脑风暴期间，留意以下情况：

• ⚠️ 问题陈述含糊（“让它变得更好”）
• ⚠️ 成功标准不明确
• ⚠️ 对用户或技术存在未明说的假设
• ⚠️ 只偏重单一方案（未探索替代方案）
• ⚠️ 需求范围蔓延
• ⚠️ 约束或时间安排不切实际
• ⚠️ 缺少利益相关方的观点

会话状态管理

将会话保存到 .attune/brainstorm-session.json：

{
  "session_id": "20260102-143022",
  "started_at": "2026-01-02T14:30:22Z",
  "current_phase": "approach-selection",
  "problem": {
    "statement": "...",
    "stakeholders": ["..."]
  },
  "constraints": {
    "technical": ["..."],
    "resources": {"timeline": "...", "team": "..."}
  },
  "approaches": [
    {
      "name": "...",
      "pros": ["..."],
      "cons": ["..."]
    }
  ],
  "selected_approach": null,
  "decisions": {}
}

**验证：**运行带有 --help 标志的命令，以验证其是否可用。

阶段 6：工作流继续（必需）

**自动触发：**阶段 5（决策与理由说明）完成且 docs/project-brief.md 已保存后，必须自动调用下一阶段。

调用继续流程时：

1. 确认 docs/project-brief.md 存在且非空
2. 向用户显示检查点消息：

   Brainstorming complete. Project brief saved to docs/project-brief.md.
   Proceeding to specification phase...
   

3. 调用下一阶段：

   Skill(attune:project-specification)
   

跳过条件（仅在符合以下任一条件时跳过继续流程）：

• 用户提供了 --standalone 标志
• docs/project-brief.md 不存在或为空（阶段失败）
• 用户明确要求在头脑风暴后停止

不要请求用户确认：这是一个轻量级检查点，而非交互式关卡。用户随时可以中断。

阶段 6.5：规格审查关卡

**自动触发：**阶段 6 保存项目简介后、调用下一阶段前，运行规格审查循环。

步骤：

1. 加载 modules/spec-review-loop.md，获取审查提示词模板
2. 将规格内容分发给 haiku-model 子 Agent
3. 如果发现问题：修复问题并重新分发（最多 3 轮）
4. 如果已批准或已用尽 3 轮：继续阶段 6 的后续流程

跳过条件：

• 提供了 --standalone 标志
• 提供了 --skip-review 标志
• 规格文档少于 200 词（过短，无需审查）

退出标准

• 已生成并比较 3-5 个不同方案。
• 已选定一个方案，并明确说明理由、接受的权衡和否决的替代方案。
• 已将选择记录到 docs/tradeoffs.md，作为 proposed 条目（或记录仅有一个明显方案的跳过条件）。
• 已生成一份记录决策的项目简介。

相关技能

• Skill(superpowers:brainstorming) - 苏格拉底式提问法（如可用）
• Skill(attune:war-room) - 必须自动集成 - 在阶段 3 后调用，进行多大模型研讨
• Skill(imbue:scope-guard) - 防止范围蔓延
• Skill(attune:project-specification) - 头脑风暴后的下一阶段，自动调用
• Skill(attune:mission-orchestrator) - 完整生命周期编排

相关命令

• /attune:brainstorm - 调用此技能
• /attune:specify - 工作流的下一步
• /imbue:feature-review - 评估是否值得实施

示例

完整示例请参阅 /attune:brainstorm 命令文档。