update

.agents/skills/brainstorming/SKILL.md

@@ -0,0 +1,193 @@
+---
+name: brainstorming
+description: 在任何创造性工作前执行此步骤——包括创建功能、构建组件、添加功能或修改行为。在实施前探究用户意图、需求与设计方案。通过自然协作对话，将创意转化为完整的设计方案与规格说明。当用户提及"新功能"、"构建"、"创建组件"、"添加功能"、"实现"或开始任何开发工作时触发本技能。本技能会自动调用 project-context 技能获取用户画像和流程路径推荐。
+license: MIT
+metadata:
+  version: "3.0.0"
+---
+
+# 头脑风暴技能
+
+本技能是任何创造性工作前的必经步骤，通过协作对话将创意转化为完整的设计规格说明。
+
+---
+
+## 核心原则
+
+### 设计优先
+
+在用户批准设计文档前，请勿：
+
+- 调用任何实施技能
+- 编写任何代码
+- 搭建项目框架
+- 采取任何实施行动
+
+### 会话状态管理
+
+使用统一的会话状态文件跟踪进度：
+
+- **路径**：`design/session-state.md`
+- **模板**：`references/session-state-template.md`
+
+**操作时机**：
+
+- 技能激活时 → **创建状态文件**，如果状态文件存在，则将旧文件重命名为：session-state-YYYYMMDDHHMMSS.md
+- 获得用户确认后 → **更新状态文件**
+- 每轮对话开始时 → 读取状态文件恢复上下文
+- **每个阶段完成后 → 更新状态文件**
+
+### 终止条件
+
+本技能的唯一终止方式是调用 `writing-plan` 技能，并传递规格文档路径。
+
+---
+
+## 工作流程
+
+### 阶段 1：探索背景
+
+**目标**：了解当前项目状态，评估需求范围。
+
+**执行动作**：
+
+1. 调用 `project-context` 技能获取用户画像
+2. 读取项目上下文（如有）：`design/context/project-context.md`
+3. 检查项目文件结构
+4. 评估需求是否涉及多个独立子系统
+5. **主动更新用户画像**（如果识别到新的偏好或技术背景）
+
+**范围检查**：
+
+- 若请求涉及多个独立子系统，协助用户分解为子项目
+- 每个子项目独立进行头脑风暴
+
+**完成标准**：已了解项目技术栈和现有结构，已确认需求范围，用户画像已更新（如有变化）
+
+---
+
+### 阶段 2：确认需求
+
+**目标**：逐条理解目标、约束条件和成功标准。
+
+**执行规则**：
+
+- 每条消息只提一个问题
+- 优先使用选择题形式
+
+**核心问题清单**（按顺序询问）：
+
+| 序号 | 问题类型 | 示例问题                         |
+| ---- | -------- | -------------------------------- |
+| 1    | 目标定位 | "这个功能的主要用户是谁？"       |
+| 2    | 约束条件 | "有没有时间或技术栈的限制？"     |
+| 3    | 成功标准 | "如何判断这个功能是否成功交付？" |
+| 4    | 边界情况 | "有没有需要特别处理的边界情况？" |
+
+**完成标准**：目标定位明确、约束条件清晰、成功标准可验证
+
+---
+
+### 阶段 3：方案选择
+
+**目标**：提供 2-3 种不同方案及其权衡分析。
+
+**执行动作**：
+
+1. 提出 2-3 种不同方案
+2. 说明每种方案的优缺点
+3. 给出推荐方案及理由
+
+**完成标准**：用户已选择一个方案
+
+> 参考：`references/tech-selection-guide.md`
+
+---
+
+### 阶段 4：设计文档
+
+**目标**：将验证通过的设计写入规格文档。
+
+**执行动作**：
+
+1. 创建规格文档：`design/specs/YYYY-MM-DD-<topic>-design.md`
+2. 包含所有已确认的内容
+3. 确保无 TODO、TBD 或占位符
+
+**文档结构**：
+
+| 章节     | 内容要求             |
+| -------- | -------------------- |
+| 概述     | 功能目标、背景上下文 |
+| 目标定位 | 主要用户和使用场景   |
+| 约束条件 | 技术、时间、资源限制 |
+| 成功标准 | 可验证的交付标准     |
+| 架构设计 | 系统结构和组件划分   |
+| 数据流   | 数据如何流转         |
+| 错误处理 | 异常情况处理策略     |
+| 测试策略 | 如何验证功能正确性   |
+
+**完成标准**：文档已写入指定路径，无占位符内容
+
+> 参考：`references/spec-template.md`
+
+---
+
+### 阶段 5：交接
+
+**目标**：获得用户批准，调用 writing-plan 技能。
+
+**执行动作**：
+
+1. 呈现规格文档路径给用户
+2. 请用户审阅并确认
+3. 若用户批准，调用 writing-plan 技能
+
+**标准话术**：
+
+> "规格文档已编写并提交至 `<path>`。请审阅，确认后我将开始制定实施计划。"
+
+**调用格式**：
+
+```
+调用 writing-plan 技能，规格文档路径：<path>
+```
+
+**终止**：此阶段完成后，本技能结束。
+
+---
+
+## 参考指南
+
+| 参考文档                                 | 用途             |
+| ---------------------------------------- | ---------------- |
+| `references/session-state-template.md`   | 会话状态文件模板 |
+| `references/spec-template.md`            | 规格文档模板     |
+| `references/tech-selection-guide.md`     | 技术选型指导     |
+| `references/risk-assessment-template.md` | 风险评估模板     |
+
+---
+
+## 常见问题
+
+### 用户坚持跳过设计直接实施？
+
+回复：
+
+> "我理解您希望快速推进。设计文档可以很简短，但需要记录并获得您的批准，这能确保我们对目标达成共识，避免后续返工。"
+
+### 项目范围过大怎么办？
+
+处理方式：
+
+1. 标记为多子系统项目
+2. 协助用户分解为独立子项目
+3. 对第一个子项目开始头脑风暴
+4. 每个子项目独立进行规格→规划→实施循环
+
+### 对话中断后如何恢复？
+
+处理方式：
+
+1. 读取会话状态文件 `design/session-state.md`
+2. 根据"下一步"继续执行

.agents/skills/brainstorming/references/risk-assessment-template.md

@@ -0,0 +1,56 @@
+# 风险评估模板
+
+本文档提供设计阶段的风险识别和评估框架。
+
+---
+
+## 风险类别
+
+| 类别 | 示例风险 |
+|------|----------|
+| 技术风险 | 技术方案未验证、依赖项不稳定、性能瓶颈 |
+| 范围风险 | 需求蔓延、功能边界模糊、依赖外部系统 |
+| 资源风险 | 人力不足、时间紧迫、技能缺口 |
+| 集成风险 | 第三方 API 变更、数据迁移复杂、兼容性问题 |
+| 安全风险 | 数据泄露、认证漏洞、权限控制缺陷 |
+
+---
+
+## 风险评估矩阵
+
+```
+              影响程度
+            低      中      高
+       ┌────────┬────────┬────────┐
+  高   │ 监控   │ 缓解   │ 优先   │
+发     ├────────┼────────┼────────┤
+生     中   │ 接受   │ 监控   │ 缓解   │
+概     ├────────┼────────┼────────┤
+率     低   │ 接受   │ 接受   │ 监控   │
+       └────────┴────────┴────────┘
+```
+
+---
+
+## 风险记录模板
+
+在规格文档中记录风险评估：
+
+```markdown
+## 风险评估
+
+| 风险描述 | 类别 | 影响 | 概率 | 缓解策略 |
+|----------|------|------|------|----------|
+| [风险] | [类别] | 高/中/低 | 高/中/低 | [应对方案] |
+```
+
+---
+
+## 缓解策略示例
+
+| 策略类型 | 适用场景 | 示例 |
+|----------|----------|------|
+| 技术验证 | 技术方案不确定 | 对不确定的技术方案进行原型验证 |
+| 增量交付 | 功能复杂度高 | 将大功能拆分为可独立交付的小功能 |
+| 备选方案 | 关键依赖风险 | 为关键依赖准备替代方案 |
+| 监控预警 | 运行时风险 | 建立关键指标的监控机制 |

.agents/skills/brainstorming/references/session-state-template.md

@@ -0,0 +1,68 @@
+# 会话状态文件模板
+
+本模板用于跟踪多轮对话中的进度，解决注意力丢失问题。
+
+---
+
+## 文件路径
+
+```
+design/session-state.md
+```
+
+所有技能共用同一状态文件，按阶段更新。
+
+---
+
+## 模板
+
+```markdown
+# 会话状态
+
+## 基本信息
+
+- **技能**: [brainstorming / writing-plan / executing-plans]
+- **主题**: [功能名称或任务描述]
+- **开始时间**: YYYY-MM-DD HH:mm
+- **最后更新**: YYYY-MM-DD HH:mm
+
+## 当前状态
+
+- **阶段**: [当前阶段名称]
+- **上一步**: [刚完成的内容]
+- **下一步**: [待执行的下一步]
+
+## 已确认内容
+
+<!-- 记录用户已确认的关键决策和信息 -->
+
+- YYYY-MM-DD HH:mm-[决策/信息 1]
+- YYYY-MM-DD HH:mm-[决策/信息 2]
+
+## 待处理问题
+
+<!-- 需要向用户询问或解决的问题 -->
+
+- [ ] [问题 1]
+- [ ] [问题 2]
+```
+
+---
+
+## 使用规则
+
+### 创建时机
+
+技能激活时创建，路径为项目根目录下的 `design/session-state.md`。
+
+### 更新时机
+
+每次获得用户确认或完成阶段性成果后更新。
+
+### 恢复时机
+
+每轮对话开始时读取，恢复上下文后继续执行。
+
+### 技能切换时
+
+技能切换时更新"技能"字段，保留已确认内容，更新当前状态。

.agents/skills/brainstorming/references/spec-template.md

@@ -0,0 +1,82 @@
+# 规格文档模板
+
+本文档提供设计规格文档的标准结构。
+
+---
+
+## 文档路径
+
+```
+design/specs/YYYY-MM-DD-<topic>-design.md
+```
+
+---
+
+## 模板
+
+```markdown
+# [功能名称] 设计规格
+
+## 概述
+
+[功能目标和背景，1-2 段]
+
+## 目标定位
+
+- **主要用户**：[用户群体]
+- **使用场景**：[典型使用场景]
+
+## 约束条件
+
+- **技术限制**：[技术栈、框架限制]
+- **时间限制**：[交付时间要求]
+- **资源限制**：[人力、预算限制]
+
+## 成功标准
+
+- [ ] [可验证的交付标准 1]
+- [ ] [可验证的交付标准 2]
+
+## 架构设计
+
+### 系统结构
+
+[系统整体架构描述]
+
+### 组件划分
+
+| 组件 | 职责 | 依赖 |
+|------|------|------|
+| [组件名] | [职责描述] | [依赖组件] |
+
+## 数据流
+
+[数据如何流转，可用文字或简单图示]
+
+## 错误处理
+
+| 错误类型 | 处理方式 |
+|----------|----------|
+| [错误类型] | [处理策略] |
+
+## 测试策略
+
+- **单元测试**：[测试范围]
+- **集成测试**：[测试范围]
+- **验收标准**：[通过条件]
+
+## 决策记录
+
+| 决策 | 理由 | 影响 |
+|------|------|------|
+| [决策内容] | [为什么] | [影响范围] |
+```
+
+---
+
+## 质量要求
+
+- 无 TODO、TBD 或占位符
+- 所有章节内容完整
+- 成功标准可验证
+- 决策有明确理由

.agents/skills/brainstorming/references/tech-selection-guide.md

@@ -0,0 +1,59 @@
+# 技术选型指导
+
+本文档提供技术选型的评估框架。
+
+---
+
+## 评估维度
+
+| 维度 | 评估问题 |
+|------|----------|
+| 团队熟悉度 | 团队是否已有相关经验？学习成本如何？ |
+| 社区生态 | 文档是否完善？遇到问题能否找到解决方案？ |
+| 长期维护 | 项目是否持续维护？向后兼容性如何？ |
+| 性能特性 | 是否满足性能需求？有无已知问题？ |
+| 集成难度 | 与现有系统的兼容性如何？迁移成本多大？ |
+
+---
+
+## 选型流程
+
+1. 明确技术约束条件（团队技能、现有技术栈、预算/时间限制）
+2. 列出候选方案（通常 2-3 个）
+3. 按评估维度对比分析
+4. 给出推荐方案及理由
+5. 在规格文档中记录选型决策
+
+---
+
+## 决策记录模板
+
+```markdown
+## 技术选型决策
+
+### 候选方案对比
+
+| 方案 | 团队熟悉度 | 社区生态 | 长期维护 | 性能特性 | 集成难度 |
+|------|------------|----------|----------|----------|----------|
+| 方案A | 高 | 高 | 高 | 中 | 低 |
+| 方案B | 中 | 高 | 高 | 高 | 中 |
+
+### 选择理由
+
+[为什么选择这个方案]
+
+### 权衡考量
+
+[牺牲了什么，换取了什么]
+```
+
+---
+
+## 常见陷阱
+
+| 陷阱 | 应对策略 |
+|------|----------|
+| 追逐流行 | 评估实际需求匹配度 |
+| 忽视学习成本 | 预留学习缓冲期 |
+| 缺乏维护支持 | 检查项目活跃度指标 |
+| 过度设计 | 遵循 YAGNI 原则 |