Requirement Analysis

需求分析技能 (Requirement Analysis Skill)

本技能强制执行系统化的需求分析工作流，确保在实施前彻底理解需求。

何时使用 (When to Use)

在以下情况下使用本技能：

• 开始新功能实施
• 接收到复杂或模糊的需求
• 在不熟悉的代码库部分工作
• 需要设计 API 端点、数据库架构或服务架构
• 修改原有功能

如何触发此技能 (How to Trigger)

方式 1: 自动触发

当你提出以下类型的需求时，Claude 应该会自动使用此技能：

• "我需要实现一个 XXX 功能"
• "帮我设计一个 XXX 的 API"
• "需要添加 XXX 数据库表"
• "开发一个 XXX 模块"
• "需要新增一个 XXX 功能"
• "需要新增一个 XXX 模块"
• "XXX 需要修改"

方式 2: 手动触发命令

显式调用技能：

/requirement-analysis

方式 3: 在消息中明确提示

在你的需求描述中加入提示语：

• "使用需求分析skill来帮我实现用户管理功能"
• "请用 requirement-analysis 技能来处理这个需求"
• "按照需求分析流程帮我设计这个 API"

推荐做法

对于复杂功能开发，建议在需求开头明确说明：

使用需求分析skill：我需要实现一个文件上传和管理系统...

工作流程 (Workflow)

阶段 1: 需求理解 (Requirement Understanding)

根据需求复杂度决定是否使用 ultrathink：

仔细阅读用户的需求并识别：

• 核心功能 (Core Functionality): 请求的主要特性/能力是什么？
• 业务实体 (Business Entities): 涉及哪些数据模型或领域对象？
• API 端点 (API Endpoints): 需要暴露哪些接口？
• 业务规则 (Business Rules): 适用哪些约束、验证或特殊逻辑？
• 输入/输出 (Input/Output): 预期的请求和响应格式是什么？

何时在此阶段使用 ultrathink：

满足以下任一条件时，应在需求理解阶段使用 ultrathink：

• ✅ 需求涉及多个模块或系统的集成
• ✅ 需求包含复杂的业务逻辑或工作流
• ✅ 需求描述模糊或不完整，需要推理补充
• ✅ 需求之间存在依赖关系或冲突
• ✅ 需要设计复杂的数据结构或关系

如果是简单的 CRUD 功能或单一模块的简单需求，可以跳过此阶段的 ultrathink，直接进入阶段 2。

阶段 2: 代码库探索 (Codebase Exploration)

首要任务: 查找并阅读项目根目录下的 CLAUDE.md 文件，理解项目规范和约定。

2.1 基础探索模式 (Basic Exploration)

适用场景：

• 简单需求，探索范围明确且单一
• 需求仅涉及单个模块或层次
• 时间不敏感的探索任务

使用方法：使用单个 Task 工具的 subagent_type=Explore：

Use Task tool with:
- subagent_type: Explore
- thoroughness: medium or very thorough (depending on complexity)
- prompt: "Find existing implementations of [related feature] including entities, services, and controllers"

2.2 并行探索模式 (Parallel Exploration) ⚡

适用场景（满足以下任一条件时使用）：

• ✅ 需求涉及多个架构层次（数据层、服务层、API层等）
• ✅ 需求涉及多个模块或子系统
• ✅ 探索任务可以清晰分解为独立的子任务
• ✅ 需要节省时间，提高探索效率

重要技术要求：

⚠️ 必须在单个 message 中发起所有并行任务。不能发送一个message调用Task，等待结果，再发送另一个message调用另一个Task。必须在同一个response中同时调用多个Task工具。

并行探索策略：

策略 1：按架构层次分解

同时启动 3 个 Explore agent（在一个 message 中）：

Agent 1 - 数据层探索：
- subagent_type: Explore
- prompt: "探索 [需求相关] 的数据模型、实体定义、数据库表结构和迁移文件"

Agent 2 - 服务层探索：
- subagent_type: Explore
- prompt: "探索 [需求相关] 的业务逻辑、服务类、验证规则和错误处理"

Agent 3 - API层探索：
- subagent_type: Explore
- prompt: "探索 [需求相关] 的控制器、路由定义、请求/响应结构和中间件"

策略 2：按功能模块分解

同时启动 2-3 个 Explore agent（在一个 message 中）：

Agent 1 - 核心功能模块：
- subagent_type: Explore
- prompt: "探索 [核心模块名] 的完整实现，包括所有层次"

Agent 2 - 关联功能模块：
- subagent_type: Explore
- prompt: "探索与 [核心模块] 集成的 [关联模块] 的实现方式"

Agent 3 - 通用工具和模式：
- subagent_type: Explore
- prompt: "探索项目中可复用的工具类、辅助函数和通用模式"

策略 3：按关注点分解

同时启动 2-4 个 Explore agent（在一个 message 中）：

Agent 1 - 现有实现：
- prompt: "查找 [功能] 的现有实现和类似功能"

Agent 2 - 错误处理模式：
- prompt: "探索项目中的错误处理、异常捕获和日志记录模式"

Agent 3 - 测试用例：
- prompt: "查找相关功能的测试文件和测试模式"

Agent 4 - 配置和常量：
- prompt: "探索项目的配置文件、环境变量和常量定义"

并行数量建议：

• 简单需求：1 个 agent（使用基础探索模式）
• 中等需求：2-3 个 agent
• 复杂需求：3-5 个 agent
• ⚠️ 不建议超过 5 个并行任务，避免过度复杂化

结果汇总：

• 等待所有并行 agent 完成
• 整合各个 agent 的发现
• 识别重复信息并去重
• 组织成结构化的探索报告
• 重点标注需要遵循的模式和约定

查找内容清单：

• CLAUDE.md - 项目的开发规范、约定和指南（必须优先查看）
• 项目中的相关实体、数据库对象
• 项目中的类似服务实现
• 项目中的控制器
• 项目中现有的请求/响应模式
• 项目中使用的通用工具和模式

阶段 2.5: 外部资源和文档研究 (External Resources & Documentation Research)

执行条件（满足以下任一条件时执行此阶段）：

• ✅ 需求涉及新的第三方库或框架
• ✅ 需要了解行业最新实践或技术方案
• ✅ 内部代码库示例不充分，需要外部参考
• ✅ 需要验证最新的 API 或文档

何时跳过此阶段：

• ⏭️ 需求完全基于已有代码，不涉及新库或技术
• ⏭️ 团队对相关技术已经非常熟悉
• ⏭️ 时间紧急且需求简单明确

目的: 在充分了解内部代码库后（阶段 2），查询外部资源以获取最新的技术方案、代码示例和库文档，为后续的深度分析（阶段 4）提供充分的信息支持。

2.5.1 高质量网页搜索 (Web Search for Code Examples)

何时使用：

• 需要查找特定技术问题的解决方案和最佳实践
• 需要了解某个技术方案的实现示例
• 需要查找代码模板或参考实现
• 需要了解行业标准做法

工具使用策略（带降级机制）：

1. 优先使用 exa MCP（如果可用）：

   • 尝试使用 exa MCP 进行高质量搜索
   • exa 专门优化了代码和技术内容的搜索
   • 如果工具调用成功，使用返回的结果

2. 降级到 WebSearch（如果 exa 不可用）：

   • 如果 exa MCP 调用失败或不可用，使用 WebSearch 工具
   • 使用精确的搜索关键词（包含技术栈、具体问题、年份）
   • 从返回结果中提取有价值的代码示例和方案

3. 降级失败处理：如果所有搜索工具都不可用，基于已有的代码库知识和经验继续工作流，并在实施计划中注明需要用户提供额外参考资源。

搜索示例：

• "Node.js Express 文件上传最佳实践 2025"
• "React hooks 状态管理模式"
• "PostgreSQL 多租户架构设计"

注意事项：

• 搜索结果应整合到后续的深度分析和实施计划中
• 优先参考官方文档和权威来源
• 验证代码示例是否适用于当前项目的技术栈

2.5.2 获取最新库文档 (Library Documentation via context7)

何时使用：

• 需求涉及特定的第三方库或框架
• 需要了解库的最新 API 和功能
• 需要查找官方推荐的使用模式
• 需要了解库的配置选项和最佳实践

工具使用策略（带降级机制）：

1. 优先使用 context7 MCP（如果可用）：

   步骤 1: 使用 mcp__context7__resolve-library-id 获取库 ID

   • 参数 libraryName: 库的名称（如 "express", "react", "next.js"）
   • 参数 query: 用户的原始问题或任务（用于相关性排序）
   • 返回值：Context7 兼容的库 ID

   步骤 2: 使用 mcp__context7__query-docs 获取文档

   • 参数 libraryId: 从步骤1获取的库 ID
   • 参数 query: 具体的查询问题（如 "how to set up routing", "middleware patterns", "hooks usage"）

2. 降级到 WebSearch + Grep + Read（如果 context7 不可用）：

   步骤 1: 使用 WebSearch 搜索官方文档

   • query: "[库名] official documentation [具体功能] 2025"
   • 从搜索结果中获取官方文档链接

   步骤 2: 使用 Grep 搜索项目中已有的使用示例

   • pattern: 相关的导入语句或 API 调用
   • 查找项目中是如何使用该库的

   步骤 3: 使用 Read 阅读找到的相关文件

   • 理解项目中的使用模式和最佳实践

3. 降级失败处理：如果所有工具都不可用，在实施计划中注明需要用户提供库的官方文档链接或确认使用的版本和 API。

使用示例：

场景：需要使用 Express.js 实现文件上传功能

使用 context7:
1. resolve-library-id: libraryName="express", query="需要使用 Express.js 实现文件上传功能"
2. query-docs: libraryId="/expressjs/express", query="file upload middleware setup and usage"

降级方案（如果 context7 不可用）:
1. WebSearch: "Express.js multer file upload official documentation 2025"
2. Grep: pattern="multer|express-fileupload" 查找项目中的使用
3. Read: 阅读相关文件了解现有实现模式

注意事项：

• 确保获取的是最新版本的文档（与项目使用的版本匹配）
• 将文档中的 API 参考和代码示例整合到实施计划中
• 注意库的使用限制和已知问题

阶段 3: 澄清问题 (Clarification Questions)

重要: 对任何不清楚、模糊、有歧义的地方，必须主动使用 AskUserQuestion 工具 向用户提问。不要假设或猜测用户的意图。

使用 AskUserQuestion 工具 来澄清：

• 模糊或规格不足的需求
• 多个有效实施方法之间的选择
• 业务规则细节或边缘情况处理
• 与现有功能的关系
• 需要验证的任何假设
• 技术选型或架构决策
• 数据格式、字段类型等具体细节

示例:

AskUserQuestion with:
- questions: [
    {
      question: "批量导入是否应同时支持 Excel 和 CSV 格式？",
      header: "文件格式",
      options: [
        {label: "同时支持 Excel 和 CSV", description: "..."},
        {label: "仅支持 Excel", description: "..."}
      ],
      multiSelect: false
    }
  ]

阶段 4: 使用顺序思考进行深度分析 (Deep Analysis with Sequential Thinking)

必须使用 ultrathink: 在此阶段必须使用 mcp__sequential-thinking__sequentialthinking 工具 (ultrathink) 进行深度思考和分析，不要跳过这一步骤。

使用 mcp__sequential-thinking__sequentialthinking 工具 来：

1. 分析需求 - 将需求分解为组件
2. 设计数据结构 - 规划数据库表、实体字段、关系（必须符合 CLAUDE.md 中的数据库设计规范）
3. 设计 API 端点 - 定义 REST 端点、请求/响应格式（必须符合 CLAUDE.md 中的 API 设计规范）
4. 设计服务层 - 规划业务逻辑、验证、错误处理（必须符合 CLAUDE.md 中的架构模式）
5. 识别风险 - 考虑边缘情况、性能、安全问题
6. 规划实施 - 概述逐步实施任务（确保符合项目规范）

思考过程示例:

• Thought 1: 分析核心需求并分解为子功能
• Thought 2: 基于业务实体设计数据库架构，检查 CLAUDE.md 中的命名约定和字段类型规范
• Thought 3: 遵循 RESTful 约定和 CLAUDE.md 中的 API 路由规范规划端点
• Thought 4: 考虑验证规则和错误场景，遵循 CLAUDE.md 中的错误处理规范
• Thought 5: 识别潜在的性能瓶颈
• Thought 6: 规划实施顺序，确保每个步骤都符合项目规范

阶段 5: 展示实施计划 (Present Implementation Plan)

完成分析后，向用户展示：

1. 需求总结 (Requirement Summary)

• 清楚说明你理解的需求
• 关键特性和能力

2. 代码库发现 (Codebase Findings)

• 发现的相关现有代码
• 要遵循的模式和约定
• 可重用的组件或工具

3. 技术设计 (Technical Design)

数据库设计

API 端点:

POST   /api/resource/create   - 创建新资源
GET    /api/resource/list     - 列出资源（分页）
PUT    /api/resource/update   - 更新资源
DELETE /api/resource/delete   - 删除资源

Service 层设计:

• 关键服务方法
• 业务逻辑流程
• 验证策略
• 错误处理方法

4. 实施步骤 (Implementation Steps)

1. 步骤 1: 创建实体和迁移
2. 步骤 2: 实施服务层
3. 步骤 3: 创建请求/响应结构
4. 步骤 4: 实施控制器
5. 步骤 5: 注册路由
6. 步骤 6: 添加验证和错误处理

5. 风险和注意事项 (Risks and Considerations)

• 潜在的技术挑战
• 需要处理的边缘情况
• 性能考虑
• 安全问题

6. 等待确认 (Wait for Confirmation)

重要: 在用户确认计划之前，不要开始实施。

询问: "这个实施计划看起来如何？我可以开始实施了吗？"

阶段 6: 实施开发 (Implementation)

前提: 必须获得用户对实施计划的明确确认后才能开始。

执行原则：

1. 严格遵循 CLAUDE.md: 所有编码约定、API 设计、数据库命名都必须与 CLAUDE.md 中定义的规范一致
2. 逐步实施: 按照阶段 5 展示的实施步骤逐个完成
3. 及时跟踪: 使用 TodoWrite 工具跟踪每个步骤的进度
4. 质量优先: 每个步骤完成后验证功能正确性，不要急于求成
5. 保持简洁: 避免过度工程，只实现计划中的功能

常见场景处理：

• 发现设计缺陷: 使用 AskUserQuestion 讨论是否需要调整计划
• 需要新增功能: 与用户确认是否在此次实施中添加
• 遇到技术障碍: 搜索参考资源或征求用户意见
• 遇到问题: 及时使用 AskUserQuestion 向用户咨询，不要自行决策重大改变

完成标准：

• 所有实施步骤都已完成
• 代码符合 CLAUDE.md 规范
• 功能已在本地验证
• 准备好进入阶段 7 的代码审查

阶段 7: 代码审查 (Code Review)

目的: 在实施完成后，系统化地审查代码质量，确保代码符合标准并且没有明显的问题。

何时执行: 在完成所有实施步骤（阶段 6）后，自动触发代码审查流程。

7.1 单一审查模式 (Single Review Mode)

适用场景：

• 简单需求，修改文件少（1-3 个文件）
• 快速审查，时间优先
• 代码改动较小且集中

使用方法：使用单个 feat-dev:code-reviewer agent 进行全面审查。

Use Task tool with:
- subagent_type: feat-dev:code-reviewer
- prompt: "审查刚刚实施的 [功能名称] 代码，检查以下方面：
  1. Bug 和逻辑错误（功能正确性）
  2. 代码风格和质量（命名、注释、可读性）
  3. 简洁性/DRY/优雅性（避免重复、恰当抽象）
  4. 项目规范遵循（符合 CLAUDE.md）
  5. 项目约定和抽象（使用已有工具和模式）

  重点审查以下文件：
  - [列出修改的文件路径]
  "

7.2 并行深度审查模式 (Parallel Deep Review Mode) ⚡

适用场景（满足以下任一条件时使用）：

• ✅ 复杂需求，修改文件多（4+ 个文件）
• ✅ 涉及多个架构层次或模块
• ✅ 需要深度审查，确保高质量
• ✅ 代码改动较大或引入新的抽象

重要技术要求：

⚠️ 必须在单个 message 中发起所有并行审查任务。在同一个response中同时调用多个Task工具，每个聚焦于不同的审查维度。

并行审查策略：

同时启动 5 个并行审查任务（在一个 message 中），每个聚焦于特定维度：

Reviewer 1 - 功能正确性审查：
- subagent_type: feat-dev:code-reviewer
- prompt: "聚焦于功能正确性，审查 [文件列表]：
  - 检查逻辑错误和潜在 Bug
  - 验证边缘情况处理
  - 检查错误处理是否完善
  - 验证数据验证是否充分
  只关注功能正确性，提供详细分析。"

Reviewer 2 - 代码风格和质量审查：
- subagent_type: feat-dev:code-reviewer
- prompt: "聚焦于代码风格和质量，审查 [文件列表]：
  - 检查命名是否清晰一致
  - 验证注释是否适当
  - 评估代码可读性
  - 检查函数和类的职责是否单一
  只关注代码风格和质量，提供详细建议。"

Reviewer 3 - 简洁性/DRY/优雅性审查：
- subagent_type: feat-dev:code-reviewer
- prompt: "聚焦于简洁性/DRY/优雅性，审查 [文件列表]：
  - 识别重复代码（DRY 原则）
  - 评估抽象是否恰当
  - 检查是否有不必要的复杂性
  - 评估代码是否优雅简洁
  只关注简洁性和优雅性，提供重构建议。"

Reviewer 4 - 项目规范遵循审查：
- subagent_type: feat-dev:code-reviewer
- prompt: "聚焦于项目规范遵循，审查 [文件列表]：
  - 验证是否符合 CLAUDE.md 编码规范
  - 检查文件结构是否符合项目约定
  - 验证 API 设计是否符合项目标准
  - 检查数据库设计是否符合命名约定
  只关注规范遵循，列出所有违规项。"

Reviewer 5 - 项目约定和抽象审查：
- subagent_type: feat-dev:code-reviewer
- prompt: "聚焦于项目约定和抽象，审查 [文件列表]：
  - 检查是否使用了项目已有工具和模式
  - 验证是否遵循项目架构模式
  - 检查是否复用了现有抽象和组件
  - 评估新增抽象是否合理且必要
  只关注约定和抽象使用，提供改进建议。"

结果汇总和报告：

1. 等待所有 5 个并行审查完成
2. 整合所有审查结果
3. 按严重性分类问题（高、中、低）
4. 组织成结构化的审查报告
5. 准备向用户展示

7.3 审查关注点 (Review Focus Areas)

无论使用哪种审查模式，以下是需要关注的5个核心维度：

1. 功能正确性 (Functional Correctness)

   • ✅ 逻辑是否正确，是否有潜在的 Bug
   • ✅ 边缘情况是否处理妥当
   • ✅ 错误处理是否完善
   • ✅ 数据验证是否充分

2. 代码风格和质量 (Code Style & Quality)

   • ✅ 命名是否清晰、一致（变量、函数、类名）
   • ✅ 注释是否适当（解释"为什么"而非"是什么"）
   • ✅ 代码可读性是否良好
   • ✅ 函数和类的职责是否单一

3. 简洁性/DRY/优雅性 (Simplicity/DRY/Elegance)

   • ✅ 是否存在重复代码（违反 DRY 原则）
   • ✅ 抽象是否恰当（既不过度也不不足）
   • ✅ 是否有不必要的复杂性
   • ✅ 代码是否优雅、简洁

4. 项目规范遵循 (Project Standards Compliance)

   • ✅ 是否符合 CLAUDE.md 中的编码规范
   • ✅ 文件结构是否符合项目约定
   • ✅ API 设计是否符合项目标准
   • ✅ 数据库设计是否符合命名约定

5. 项目约定和抽象 (Project Conventions & Abstractions)

   • ✅ 是否使用了项目中已有的工具和模式
   • ✅ 是否遵循项目的架构模式
   • ✅ 是否复用了现有的抽象和组件
   • ✅ 新增的抽象是否合理且必要

7.4 用户确认机制 (User Confirmation) ⚠️

关键要求：

⚠️ 在实施任何审查修改之前，必须使用 AskUserQuestion 工具征求用户确认。不得自动修复问题。

展示审查报告：

首先向用户展示完整的审查结果（使用7.5的输出格式），然后使用 AskUserQuestion 工具询问用户：

Use AskUserQuestion tool with:
questions: [
  {
    question: "代码审查已完成。发现了 [X个高严重性] / [Y个中严重性] / [Z个低严重性] 问题。您希望如何处理这些问题？",
    header: "审查处理",
    options: [
      {
        label: "立即修复所有高严重性问题（推荐）",
        description: "自动修复所有高严重性的Bug、安全漏洞和严重规范违反，其他问题保留待处理"
      },
      {
        label: "修复所有发现的问题",
        description: "修复所有严重性级别的问题，包括代码风格和优化建议"
      },
      {
        label: "仅修复我指定的问题",
        description: "我会在接下来的消息中告诉你需要修复哪些具体问题"
      },
      {
        label: "暂时不修复，继续其他工作",
        description: "保留审查报告，稍后再处理这些问题"
      }
    ],
    multiSelect: false
  }
]

根据用户选择执行：

• 选项1（推荐）：只修复高严重性问题，跳过低优先级的优化建议
• 选项2：修复所有问题，包括代码风格和DRY优化
• 选项3：等待用户指定具体要修复的问题
• 选项4：不进行修复，结束审查流程

修复后的验证：

• 如果进行了修复，使用 TodoWrite 跟踪修复进度
• 修复完成后，向用户报告修复结果
• 询问用户是否需要重新审查修复后的代码

7.5 输出审查报告 (Review Report)

向用户展示审查结果：

## 🔍 代码审查结果

### 审查模式
- 使用模式: [单一审查 / 并行深度审查]
- 审查文件数: [数量]
- 审查时间: [时间]

### 审查概要
- **高严重性问题**: [数量] 个 🔴
- **中严重性问题**: [数量] 个 🟡
- **低严重性问题**: [数量] 个 🟢
- **整体评价**: [优秀 / 良好 / 需要改进 / 存在严重问题]

### 详细审查结果

#### 1. 功能正确性 ✅/⚠️/❌
[来自 Reviewer 1 的详细发现]
- 发现的问题（如有）
- 具体位置和描述
- 严重性评级

#### 2. 代码风格和质量 ✅/⚠️/❌
[来自 Reviewer 2 的详细发现]
- 发现的问题（如有）
- 具体位置和描述
- 改进建议

#### 3. 简洁性/DRY/优雅性 ✅/⚠️/❌
[来自 Reviewer 3 的详细发现]
- 重复代码位置（如有）
- 过度/不足抽象（如有）
- 重构建议

#### 4. 项目规范遵循 ✅/⚠️/❌
[来自 Reviewer 4 的详细发现]
- 规范违反项（如有）
- 不符合 CLAUDE.md 的地方
- 需要调整的部分

#### 5. 项目约定和抽象 ✅/⚠️/❌
[来自 Reviewer 5 的详细发现]
- 未使用已有工具/模式的地方（如有）
- 不合理的新抽象（如有）
- 改进建议

### 高严重性问题清单（需优先修复）
1. [问题1 - 文件:行号 - 描述]
2. [问题2 - 文件:行号 - 描述]
...

### 中严重性问题清单
1. [问题1]
2. [问题2]
...

### 低严重性问题和优化建议
1. [建议1]
2. [建议2]
...

重要提醒：

• ⚠️ 如果发现严重Bug、安全漏洞或数据丢失风险，必须在报告中明确标注为"关键问题"
• ⚠️ 关键问题必须强烈建议用户立即修复
• ✅ 对于代码风格、优化建议等低优先级问题，说明这些是可选的改进

重要原则 (Important Principles)

1. 全程使用中文: 与用户的所有沟通、分析报告、实施计划必须使用中文（技术术语和代码除外）
2. 严格遵循 CLAUDE.md 规范: 必须阅读并遵守项目根目录下的 CLAUDE.md 文件中制定的所有开发规范、编码约定和架构指南
3. 主动提问: 对任何不清楚、模糊、有歧义的地方，必须主动向用户提问澄清，不要假设或猜测
4. 合理使用 ultrathink:
   • 阶段 1（需求理解）：根据复杂度决定是否使用
   • 阶段 4（深度分析）：必须使用 Sequential Thinking 工具进行系统化思考
5. 善用外部资源:
   • 阶段 2.5：在需要时使用网页搜索和 context7 获取外部资源
   • 优先使用 exa MCP（网页搜索）和 context7 MCP（库文档）
   • 遇到工具不可用时，使用降级方案（WebSearch、Grep、Read）
6. 合理使用并行化 ⚡:
   • 阶段 2（代码探索）：复杂需求使用并行探索模式，3-5个agent同时探索不同层次或模块
   • 阶段 7（代码审查）：大型改动使用并行深度审查模式，5个agent同时审查不同维度
   • 技术要求：必须在单个message中发起所有并行任务，不能分多次调用
   • 适度使用：简单需求使用单一模式即可，不要过度并行化
7. 必须代码审查: 实施完成后必须执行阶段 7 的代码审查流程
8. 审查前必须用户确认: 在实施任何审查修改前，必须使用 AskUserQuestion 征求用户确认，不得自动修复
9. 切勿急躁: 在计划被确认之前不要开始编码
10. 善用工具: 充分利用 Explore agent 和其他分析工具
11. 保持彻底: 考虑边缘情况、错误和性能

使用示例 (Example Usage)

示例 1: 复杂需求（使用并行探索和并行深度审查）

用户: "我需要一个用户活动跟踪功能来记录用户操作，支持多租户隔离和实时分析"

使用本技能的助手：

1. 阶段 1 - 需求理解：判断为复杂需求（涉及多租户、实时分析），使用 ultrathink 分析需求
2. 阶段 2 - 代码库探索（并行模式）：
   • 并行启动 3 个 Explore agent（在一个message中）：
     • Agent 1: 探索数据模型和多租户架构
     • Agent 2: 探索服务层的日志/审计功能实现
     • Agent 3: 探索API控制器和实时通信机制
   • 汇总3个agent的探索结果
3. 阶段 2.5 - 外部资源研究：
   • 使用 context7 查询实时分析库（如 Redis、InfluxDB）的最新文档
   • 使用网页搜索查找多租户活动跟踪的最佳实践和代码示例
4. 阶段 3 - 澄清问题："应该跟踪哪些类型的操作？数据保留策略是什么？"
5. 阶段 4 - 深度分析：使用 ultrathink 设计架构和实施方案（遵循 CLAUDE.md 规范）
6. 阶段 5 - 展示计划：显示完整计划，包括实体设计、API 端点、实施步骤
7. 等待确认：在开始编码之前获得用户确认
8. 阶段 6 - 实施开发：按照计划逐步实施功能（修改了 8 个文件）
9. 阶段 7 - 代码审查（并行深度审查模式）：
   • 并行启动 5 个审查任务（在一个message中）：
     • Reviewer 1: 聚焦于功能正确性
     • Reviewer 2: 聚焦于代码风格和质量
     • Reviewer 3: 聚焦于简洁性/DRY/优雅性
     • Reviewer 4: 聚焦于项目规范遵循
     • Reviewer 5: 聚焦于项目约定和抽象
   • 汇总所有审查结果，向用户展示报告
   • 使用 AskUserQuestion 询问用户如何处理发现的问题
   • 根据用户选择进行修复

示例 2: 简单需求（使用单一模式）

用户: "给用户表添加一个手机号字段"

使用本技能的助手：

1. 阶段 1 - 需求理解：判断为简单需求（单一字段添加），跳过此阶段的 ultrathink
2. 阶段 2 - 代码库探索（基础模式）：
   • 使用单个 Explore agent 查找用户实体定义和相关迁移文件
3. 阶段 2.5 - 外部资源研究：跳过（不需要外部资源）
4. 阶段 3 - 澄清问题："手机号是否需要验证？是否允许为空？"
5. 阶段 4 - 深度分析：使用 ultrathink 考虑字段类型、验证规则、索引等（遵循 CLAUDE.md 规范）
6. 阶段 5 - 展示计划：显示完整计划
7. 等待确认：获得确认
8. 阶段 6 - 实施开发：添加字段、迁移和验证逻辑（修改了 2-3 个文件）
9. 阶段 7 - 代码审查（单一审查模式）：
   • 使用单个 code-reviewer agent 进行全面审查
   • 向用户展示审查报告
   • 使用 AskUserQuestion 询问用户如何处理发现的问题
   • 根据用户选择进行修复（如需）

示例 3: 使用第三方库的需求（重点使用 context7）

用户: "使用 Socket.io 实现实时通知功能"

使用本技能的助手：

1. 阶段 1 - 需求理解：识别需要使用 Socket.io 库
2. 阶段 2 - 代码库探索：查找项目中是否已有 WebSocket 或实时通信相关代码
3. 阶段 2.5 - 外部资源研究：
   • 使用 context7 查询 Socket.io 最新文档：
     • resolve-library-id: libraryName="socket.io", query="使用 Socket.io 实现实时通知功能"
     • query-docs: libraryId="/socket.io/socket.io", query="server setup and events handling"
   • 如果 context7 不可用，降级到 WebSearch 搜索官方文档
4. 阶段 3 - 澄清问题："需要支持哪些类型的通知？是否需要通知历史记录？"
5. 阶段 4 - 深度分析：基于 Socket.io 最新 API 设计实现方案
6. 阶段 5 - 展示计划：展示集成 Socket.io 的完整计划
7. 等待确认：获得确认
8. 阶段 6 - 实施开发：按计划实施
9. 阶段 7 - 代码审查：确保正确使用 Socket.io API 和最佳实践

输出格式模板 (Output Format Template)

## 🎯 需求理解
- [我理解的要点列表]

## 🔍 代码库探索结果
- **CLAUDE.md 规范**: [项目规范的关键要点 - 命名约定、架构模式、编码规范等]
- **发现**: [相关的现有代码]
- **模式**: [要遵循的约定]

## 🌐 外部资源研究（如适用）

### 网页搜索结果
- **搜索主题**: [搜索的具体问题或技术]
- **关键发现**: [从搜索结果中提取的有价值信息]
- **代码示例**: [相关的代码片段或实现方案]
- **最佳实践**: [行业标准做法或推荐模式]

### 库文档查询结果
- **查询的库**: [库名称和版本]
- **相关 API**: [查询到的 API 和方法]
- **官方示例**: [官方文档中的代码示例]
- **注意事项**: [使用限制、已知问题等]

## ❓ 需要澄清的问题
[AskUserQuestion 工具结果 或 "无疑问 - 需求很清楚"]

## 🧠 深度分析 (使用 ultrathink)
[Sequential Thinking 顺序思考结果 - 技术设计决策，必须体现如何遵循 CLAUDE.md 规范]

## 📋 实施计划

### 数据库设计
[实体定义 - 遵循 CLAUDE.md 中的命名和字段规范]

### API 端点
[带方法和路径的端点列表 - 遵循 CLAUDE.md 中的 API 设计规范]

### Service 层
[服务方法签名和逻辑流程 - 遵循 CLAUDE.md 中的架构模式]

### 实施步骤
[编号的步骤列表 - 确保每步符合项目规范]

### 风险和注意事项
[需要注意的潜在问题]

### 规范遵循检查
- [ ] 数据库设计符合 CLAUDE.md 规范
- [ ] API 端点符合 CLAUDE.md 规范
- [ ] 代码结构符合 CLAUDE.md 规范
- [ ] 命名约定符合 CLAUDE.md 规范

## ✅ 准备好继续了吗？
这个计划看起来如何？我可以开始实施了吗？

---

## 🔍 代码审查结果（实施完成后）

### 审查概要
- 审查文件数: [数量]
- 发现问题: [严重/一般/建议]
- 整体评价: [优秀/良好/需要改进]

### 审查详情
- **功能正确性**: ✅/⚠️/❌ [具体评价]
- **代码风格和质量**: ✅/⚠️/❌ [具体评价]
- **简洁性/DRY/优雅性**: ✅/⚠️/❌ [具体评价]
- **项目规范遵循**: ✅/⚠️/❌ [具体评价]
- **项目约定和抽象**: ✅/⚠️/❌ [具体评价]

### 需要修复的问题
[如有问题，列出并说明严重性]

### 优化建议
[可选的改进建议]