# feature-dev-pro

**Repository Path**: stoennnnn/feature-dev-pro

## Basic Information

- **Project Name**: feature-dev-pro
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Apache-2.0
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-06-12
- **Last Updated**: 2026-06-12

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 功能开发插件

一个全面、结构化的功能开发工作流，配备专门的智能体用于代码库探索、架构设计和质量审查。

## 概述

功能开发插件提供了一种系统化的7阶段方法来构建新功能。它不会让你直接跳入编码，而是引导你理解代码库、提出澄清问题、设计架构并确保质量——从而创建出与现有代码无缝集成的、设计更优的功能。

## 理念

构建功能不仅仅是编写代码。你需要：
- 在修改前**理解代码库**
- **提出问题**以澄清模糊的需求
- 在实现前**深思熟虑地设计**
- 构建后**进行质量审查**

本插件将这些实践嵌入到一个结构化的工作流中，当你使用 `/feature-dev` 命令时会自动运行。

## 命令：`/feature-dev`

启动一个包含7个不同阶段的引导式功能开发工作流。

**用法：**
```bash
/feature-dev 添加基于OAuth的用户认证
```

或者简单地：
```bash
/feature-dev
```

该命令将交互式地引导你完成整个过程。

## 7阶段工作流

### 阶段1：发现

**目标**：理解需要构建什么

**会发生什么：**
- 如果功能请求不清晰，则进行澄清
- 询问你要解决什么问题
- 识别约束和需求
- 总结理解并与你确认

**示例：**
```
你：/feature-dev 添加缓存
Claude：让我理解你的需求...
        - 应该缓存什么？（API响应、计算值等）
        - 你的性能要求是什么？
        - 你有首选的缓存解决方案吗？
```

### 阶段2：代码库探索

**目标**：理解相关的现有代码和模式

**会发生什么：**
- 并行启动2-3个`code-explorer`智能体
- 每个智能体探索不同方面（类似功能、架构、UI模式）
- 智能体返回包含关键文件的全面分析
- Claude读取所有识别的文件以建立深入理解
- 呈现全面的发现摘要

**启动的智能体：**
- "查找类似于[功能]的功能并追踪实现"
- "映射[区域]的架构和抽象"
- "分析[相关功能]的当前实现"

**示例输出：**
```
找到的类似功能：
- 用户认证 (src/auth/)：使用JWT令牌、中间件模式
- 会话管理 (src/session/)：Redis支持，24小时过期
- API安全 (src/api/middleware/)：速率限制、CORS

需要理解的关键文件：
- src/auth/AuthService.ts:45 - 核心认证逻辑
- src/middleware/authMiddleware.ts:12 - 请求认证
- src/config/security.ts:8 - 安全配置
```

### 阶段3：澄清问题

**目标**：填补空白并解决所有歧义

**会发生什么：**
- 审查代码库发现和功能请求
- 识别未明确指定的方面：
  - 边界情况
  - 错误处理
  - 集成点
  - 向后兼容性
  - 性能需求
- 以有组织的列表呈现所有问题
- **在继续之前等待你的回答**

**示例：**
```
在设计架构之前，我需要澄清：

1. OAuth提供商：哪些OAuth提供商？（Google、GitHub、自定义？）
2. 用户数据：存储OAuth令牌还是仅存储用户资料？
3. 现有认证：替换现有认证还是并行添加？
4. 会话：与现有会话管理集成？
5. 错误处理：如何处理OAuth失败？
```

**关键**：此阶段确保在设计开始前没有歧义。

### 阶段4：架构设计

**目标**：设计多种实现方法

**会发生什么：**
- 启动2-3个具有不同侧重点的`code-architect`智能体：
  - **最小更改**：最小更改，最大复用
  - **清洁架构**：可维护性，优雅抽象
  - **实用平衡**：速度+质量
- 审查所有方法
- 形成哪种方法最适合此任务的观点
- 呈现包含权衡和建议的比较
- **询问你偏好哪种方法**

**示例输出：**
```
我设计了3种方法：

方法1：最小更改
- 扩展现有AuthService以添加OAuth方法
- 将新OAuth路由添加到现有auth路由器
- 需要最少的重构
优点：快速，低风险
缺点：将OAuth耦合到现有auth，更难测试

方法2：清洁架构
- 新OAuthService具有专用接口
- 单独的OAuth路由器和中间件
- 重构AuthService以使用通用接口
优点：清晰分离，可测试，可维护
缺点：更多文件，更多重构

方法3：实用平衡
- 新OAuthProvider抽象
- 集成到现有AuthService中
- 最小重构，良好的边界
优点：复杂性和清洁性平衡
缺点：仍有一些耦合

建议：方法3 - 为你提供清晰的边界而无需过度重构，并且非常适合你的现有架构。

你想使用哪种方法？
```

### 阶段5：实现

**目标**：构建功能

**会发生什么：**
- **在开始前等待明确批准**
- 读取前几个阶段识别的所有相关文件
- 按照所选架构实现
- 严格遵循代码库约定
- 编写清晰、文档完善的代码
- 随着进度更新待办事项

**注意：**
- 实现只在你批准后开始
- 遵循阶段2中发现的模式
- 使用阶段4中设计的架构
- 持续跟踪进度

### 阶段6：质量审查

**目标**：确保代码简单、DRY、优雅且功能正确

**会发生什么：**
- 并行启动3个具有不同侧重点的`code-reviewer`智能体：
  - **简单性/DRY/优雅**：代码质量和可维护性
  - **错误/正确性**：功能正确性和逻辑错误
  - **约定/抽象**：项目标准和模式
- 整合发现
- 识别最高严重性问题
- **呈现发现并询问你想做什么**：
  - 立即修复
  - 稍后修复
  - 按原样继续
- 根据你的决定解决问题

**示例输出：**
```
代码审查结果：

高优先级问题：
1. OAuth回调中缺少错误处理 (src/auth/oauth.ts:67)
2. 内存泄漏：OAuth状态未清理 (src/auth/oauth.ts:89)

中优先级：
1. 可以简化令牌刷新逻辑 (src/auth/oauth.ts:120)
2. 考虑提取OAuth配置验证

所有测试通过。代码遵循项目约定。

你想做什么？
```

### 阶段7：总结

**目标**：记录完成的工作

**会发生什么：**
- 标记所有待办事项为完成
- 总结：
  - 构建了什么
  - 做出的关键决策
  - 修改的文件
  - 建议的后续步骤

**示例：**
```
功能完成：OAuth认证

构建内容：
- 支持Google和GitHub的OAuth提供商抽象
- 与现有认证集成的OAuth路由和中间件
- 令牌刷新和会话集成
- 所有OAuth流的错误处理

关键决策：
- 使用具有OAuthProvider抽象的实用方法
- 与现有会话管理集成
- 添加OAuth状态以防止CSRF

修改的文件：
- src/auth/OAuthProvider.ts (新文件)
- src/auth/AuthService.ts
- src/routes/auth.ts
- src/middleware/authMiddleware.ts

建议的后续步骤：
- 为OAuth流添加测试
- 添加更多OAuth提供商（Microsoft、Apple）
- 更新文档
```

## 智能体

### `code-explorer`

**目的**：通过追踪执行路径深入分析现有代码库功能

**重点领域：**
- 入口点和调用链
- 数据流和转换
- 架构层和模式
- 依赖和集成
- 实现细节

**触发时机：**
- 在阶段2中自动触发
- 在探索代码时可手动调用

**输出：**
- 带有文件:行号引用的入口点
- 逐步执行流
- 关键组件和职责
- 架构洞察
- 必读文件列表

### `code-architect`

**目的**：设计功能架构和实现蓝图

**重点领域：**
- 代码库模式分析
- 架构决策
- 组件设计
- 实现路线图
- 数据流和构建序列

**触发时机：**
- 在阶段4中自动触发
- 在架构设计时可手动调用

**输出：**
- 发现的模式和约定
- 带有理由的架构决策
- 完整的组件设计
- 带有具体文件的实现映射
- 带有阶段的构建序列

### `code-reviewer`

**目的**：审查代码中的错误、质量问题和项目约定

**重点领域：**
- 项目指南合规性 (CLAUDE.md)
- 错误检测
- 代码质量问题
- 基于置信度的过滤（仅报告置信度≥80的高置信度问题）

**触发时机：**
- 在阶段6中自动触发
- 在编写代码后可手动调用

**输出：**
- 关键问题（置信度75-100）
- 重要问题（置信度50-74）
- 带有文件:行号引用的具体修复
- 项目指南引用

## 使用模式

### 完整工作流（推荐用于新功能）：
```bash
/feature-dev 为API端点添加速率限制
```

让工作流引导你完成所有7个阶段。

### 手动智能体调用：

**探索功能：**
```
"启动code-explorer以追踪认证如何工作"
```

**设计架构：**
```
"启动code-architect以设计缓存层"
```

**审查代码：**
```
"启动code-reviewer以检查我最近的更改"
```

## 最佳实践

1. **对复杂功能使用完整工作流**：7个阶段确保彻底规划
2. **深思熟虑地回答澄清问题**：阶段3防止未来的混淆
3. **有意识地选择架构**：阶段4给你选项是有原因的
4. **不要跳过代码审查**：阶段6在问题进入生产前捕获它们
5. **阅读建议的文件**：阶段2识别关键文件——阅读它们以理解上下文

## 何时使用此插件

**适用于：**
- 涉及多个文件的新功能
- 需要架构决策的功能
- 与现有代码的复杂集成
- 需求有些模糊的功能

**不适用于：**
- 单行错误修复
- 微小更改
- 定义明确、简单的任务
- 紧急热修复

## 要求

- 已安装Claude Code
- Git仓库（用于代码审查）
- 具有现有代码库的项目（工作流假设要学习的现有代码）

## 故障排除

### 智能体耗时过长

**问题**：代码探索或架构智能体速度慢

**解决方案**：
- 对于大型代码库来说这是正常的
- 智能体在可能时并行运行
- 彻底性会带来更好的理解

### 澄清问题过多

**问题**：阶段3提出的问题过多

**解决方案**：
- 在初始功能请求中更加具体
- 提前提供关于约束的上下文
- 如果确实没有偏好，可以说"你认为最佳即可"

### 架构选项过多

**问题**：阶段4的架构选项过多

**解决方案**：
- 信任建议——它基于代码库分析
- 如果仍然不确定，要求更多解释
- 有疑问时选择实用选项

## 提示

- **在功能请求中具体**：更多细节 = 更少澄清问题
- **信任过程**：每个阶段都建立在前一个阶段的基础上
- **审查智能体输出**：智能体提供关于代码库的宝贵见解
- **不要跳过阶段**：每个阶段都有其目的
- **用于学习**：探索阶段教你关于自己代码库的知识

## 作者

Sid Bidasaria (sbidasaria@anthropic.com)

## 版本

1.0.0