brainstorming

name	brainstorming
description	任何编码开始前激活。苏格拉底式需求澄清 → 项目类型检测 → L4勘探 → 大纲先行 → 保存6节roadmap。柔性技能。

在任何编码任务开始之前，你必须使用此技能。不要直接跳到写代码。 即使你认为"需求已经很清楚了"，也要走一遍这个流程。

Brainstorming：需求澄清 + 项目类型检测 + L4 勘探 + 大纲先行

技能类型：柔性

四个步骤一个都不能少。将原则适配到具体上下文。

---

工作流

用户需求 → 第一步：需求澄清（苏格拉底式提问 + 测试场景设计）
         → 第二步：项目类型检测 + L4 勘探（项目版图 + 可复用组件）
         → 第三步：大纲先行（设计文档 → 保存 6 节 roadmap 到插件 knowledge-base）
         → 进入 writing-plans

---

第一步：需求澄清

不要假设你理解了用户的意图。 用提问来提炼模糊的想法。

苏格拉底式提问框架（至少覆盖 6 个维度）

维度	要搞清楚的问题
目标	要解决什么问题？谁会用它？
范围	MVP 包含什么？什么明确不做？
约束	技术栈限制？性能要求？兼容性？
替代方案	有没有更简单的实现方式？现有工具/库能否直接解决？
验收标准	怎么判断做完了？怎么算"正确"？
测试场景	多用户隔离？权限边界？空值/null/极值？并发冲突？

两层测试场景设计（必做）

实现会限制你的想象力。代码写完了再想测试，你只会测实现能通过的场景。

层级	覆盖范围	时机
子功能全量测试	该功能的边界/null/异常/并发，每类 ≥2 条	implementing 阶段每个子功能完成后
全场景集成测试	跨功能的组合场景、完整业务流程	所有子功能通过后

类别	示例
多用户/隔离	用户 A 的数据 ≠ 用户 B 的数据；不同角色的权限边界
边界条件	null、空列表、极大值、极短/超长输入
并发/竞态	同时操作冲突？重复提交？
异常路径	依赖服务挂了？超时？非法参数？

每类每层至少 2 条测试场景，写入设计大纲的"测试场景设计"栏。

关键行为准则

• 分块展示设计：分 3-5 个可消化部分呈现，每部分等用户确认后再继续
• 主动提出替代方案：看到更简单的方法就说出来
• 明确标注不确定的：标注"待确认"而不是猜测
• 保存到 knowledge-base：大纲保存到 knowledge-base/{项目名}/{项目名}-roadmap.md

---

第二步：项目类型检测 + L4 勘探

2.1 项目类型检测（必做）

在勘探之前，先判断项目类型。 不同类型走不同的勘探清单和实现策略。

自动检测规则：

检测项：
├─ .claude-plugin/ 或 plugin.json 存在？ → 插件项目
├─ pom.xml 或 build.gradle 存在？
│   ├─ 同时有 package.json（vue/react/angular）？ → 全栈项目
│   ├─ 仅 Java 构建文件？ → 纯后端项目
│   └─ 仅 package.json？ → 纯前端项目
└─ 无构建文件？ → 通用项目（文档/脚本）

项目类型	勘探重点	Roadmap §3 记录内容
后端	模块/端口/包结构、已有 DTO/Entity/Service	API 接口清单
前端	组件树/路由/状态管理/API 调用模式	组件+路由清单
全栈	前后端均勘探	API + 组件清单
插件	技能列表/Hook/配置	技能+Hook 清单

检测结果展示给用户确认后，写入 roadmap §1（项目概览）。

2.2 L4 项目勘探

在不知道项目有什么之前，你不知道什么能做。L4 是唯一真相源。

勘探清单

#	目标	操作
1	项目结构	列出所有模块/服务、端口、包结构、职责
2	已有 DTO/实体	Glob **/dto/**, **/entity/**, **/vo/**（后端/全栈）
3	已有工具类	Grep **/utils/**, **/common/**
4	已有接口	Grep interface.*Service, interface.*Mapper（后端/全栈）
5	代码模式	找 3-5 个类似功能，看分页/异常处理/返回格式
6	配置规则	配置文件在哪？Nacos？bootstrap？环境变量？
7	依赖清单	pom.xml / build.gradle 中已有的关键依赖

输出"项目版图速查"：模块表 + 可复用关键类表 + 代码模式列表 + 本次需求相关组件。

关键：已有项目必须将现有封装方法、接口、实现形式记录到 roadmap §4（现有封装方法索引），后续实现时先查此节防重复造轮子。

2.3 并行勘探模式（大项目推荐）

项目有 >5 个模块或代码量很大时，将 7 项勘探清单拆分为 3-4 个并行 Scout 子代理：

并行派发 3-4 个 Scout 子代理（Agent 工具，只读）：

Scout A — 项目结构:
  SCOPE: 项目根目录构建文件 + 所有模块目录
  GOAL: 列出所有模块/服务名、端口、包结构、职责
  RETURN: 模块表

Scout B — DTO/Entity + 工具类:
  SCOPE: **\/dto/**, **\/entity/**, **\/vo/**, **\/utils/**, **\/common/**
  GOAL: 找到已有 DTO/Entity/VO + 工具类
  RETURN: 可复用类表

Scout C — 接口 + 代码模式:
  SCOPE: **\/service/**, **\/controller/**
  GOAL: 找到已有 Service/Controller 接口签名 + 3-5 个代码模式
  RETURN: 接口列表 + 代码模式列表

Scout D — 配置 + 依赖:
  SCOPE: **\/resources/*.yml|*.yaml|*.properties, pom.xml|build.gradle
  GOAL: 列出配置项位置、关键依赖
  RETURN: 配置摘要 + 依赖清单

小项目（≤3 模块）：主代理串行勘探即可。

---

第三步：大纲先行

在写代码之前，必须先有设计大纲。没有蓝图的施工必然返工。

设计大纲必须包含

要素	说明
要做什么	一句话 + 为什么
模块划分	新建/修改哪些文件，各自职责
数据流	数据从哪来 → 经过什么处理 → 到哪去
关键决策	为什么选这个方案（含放弃的替代方案）
涉及文件	预估要改/新建的文件清单
影响范围	改了会不会影响其他功能？
验证方式	怎么确认改对了？
测试场景设计	两层 × 4 类场景，每类 ≥2 条（来自第一步）
步骤 Checklist	可勾选的施工步骤

保存到 6 节 Roadmap

所有项目统一使用 6 节 roadmap 结构（{项目名}-roadmap.md）：

# {项目名} 项目路线

## 1. 项目概览
技术栈、架构决策、项目类型

## 2. 阶段规划
每阶段目标 + Feature 清单 + 状态

## 3. 接口清单
后端 API / 前端组件路由 / 插件技能+Hook（按类型自适应）

## 4. 现有封装方法索引
已有项目的 Service/工具类/DTO/中间件等（防重复造轮子）

## 5. 实现记录
每功能的审查结果、测试覆盖、边界情况（按时间倒序）

## 6. 经验提炼
本项目踩坑 + 可跨项目复用的模式

新项目：创建 knowledge-base/{项目名}/ 文件夹，按此结构写入 roadmap。

已有项目新增功能：展示设计大纲获确认后，追加到已有 roadmap 的对应节。

experience.md 处理：已有项目如存在 experience.md，将其内容迁移到 roadmap §4（封装方法）+ §6（经验提炼），迁移后删除。不再创建新的 experience.md。

---

Red Flags — 你在跳过思考

你的想法	真相
"需求已经很清楚了"	真清楚走一遍只需 2 分钟。花更久说明并不清楚。
"项目我很熟了，不用勘探"	项目在变。至少验证前 3 个关键类的签名。
"就改一行，不写大纲"	一行改错花 2 小时排查。花 30 秒写 mini 大纲。
"测试场景跑一遍代码就知道了"	代码写完了再想测试已经晚了——实现限制思维。
"这个项目类型不用检测"	类型决定勘探策略和 roadmap §3 内容。2 分钟检测省后续混乱。

---

完成标准

进入 writing-plans 前必须确认：

• 用户需求已明确（目标、范围、约束、验收标准）
• 项目类型已检测并确认
• L4 项目版图已了解（模块/已有类/代码模式/配置）
• 设计大纲已写出（含两层测试场景设计）
• 用户已确认设计大纲
• 大纲已保存到 6 节 roadmap（knowledge-base/{项目名}/{项目名}-roadmap.md）
• 项目信息仅记录于插件 knowledge-base roadmap，不写入项目文件