Feature Development 插件：插件系统实践案例

Feature Development 插件完美展示了 Claude Code 插件系统的四大核心组件：斜杠命令、专用 Agent、Agent 技能 和 事件驱动 Hooks。让我通过这个插件来深入讲解。

一、插件概览：结构化功能开发

这个插件提供了一个 7 阶段的系统化工作流，确保在写代码之前先理解代码库、明确需求、设计架构，最后进行质量审查。

核心思想：好代码不是写出来的，是设计出来的。

文件结构：

plugins/feature-dev/
├── README.md                    # 插件文档
├── commands/
│   └── feature-dev.md          # 斜杠命令定义
└── agents/
    ├── code-explorer.md        # 代码探索 Agent
    ├── code-architect.md       # 架构设计 Agent
    └── code-reviewer.md        # 代码审查 Agent

二、斜杠命令：工作流入口

文件位置：feature-dev.md

斜杠命令是用户与插件交互的入口点。/feature-dev 命令启动完整的 7 阶段工作流：

使用方式

/feature-dev Add user authentication with OAuth
# 或者直接启动交互式流程
/feature-dev

命令元数据

在命令文件顶部的 frontmatter 定义：

---
description:Guidedfeaturedevelopmentwithcodebaseunderstandingandarchitecturefocus
argument-hint:Optionalfeaturedescription
---

这定义了命令的描述和参数提示，让用户知道这个命令是做什么的。

三、专用 Agent：专业化分工

这个插件定义了三个专用 Agent，每个 Agent 负责特定领域的深度分析：

1. Code Explorer Agent（代码探索者）

文件位置：code-explorer.md

职责：深入分析现有代码库功能，追踪执行路径、映射架构层、理解模式和抽象

核心能力：

• • 功能发现：找到入口点、核心实现文件、映射边界
• • 代码流追踪：从入口到输出，追踪数据转换
• • 架构分析：映射抽象层、识别设计模式
• • 实现细节：关键算法、错误处理、性能考虑

Agent 元数据：

---
name:code-explorer
description:Deeplyanalyzesexistingcodebasefeatures...
tools:Glob,Grep,LS,Read,NotebookRead,WebFetch,TodoWrite,WebSearch,KillShell,BashOutput
model:sonnet
color:yellow
---

工作流程示例：

Prompt: "Find features similar to OAuth and trace through their implementation"
Output: 
- Entry points: src/auth/AuthService.ts:45
- Key components: AuthMiddleware, TokenManager, UserSession
- Architecture patterns: middleware chain, dependency injection
- Files to read: [完整列表]

2. Code Architect Agent（架构师）

文件位置：code-architect.md

职责：通过分析现有代码库模式和约定，提供完整的架构设计蓝图

核心流程：

1. 1. 代码库模式分析：提取现有模式、约定、架构决策
2. 2. 架构设计：基于发现的模式设计完整架构
3. 3. 实现蓝图：指定每个要创建/修改的文件

设计决策的三个维度：

• • 最小改动：最小化变更，最大化复用
• • 清晰架构：可维护性，优雅抽象
• • 务实平衡：速度 + 质量

输出格式：

-Patterns&Conventions Found: [现有模式及引用]
-Architecture Decision: [选择的方法及理由]
-Component Design: [组件设计]
-Implementation Map: [具体文件变更]
-Data Flow: [数据流图]
-Build Sequence: [分阶段检查清单]
-Critical Details: [错误处理、状态管理、测试等]

3. Code Reviewer Agent（代码审查员）

文件位置：code-reviewer.md

职责：审查代码的 Bug、逻辑错误、安全漏洞、代码质量问题和项目约定符合性

审查范围：

• • 项目指南合规性：验证 CLAUDE.md 中的规则
• • Bug 检测：逻辑错误、空值处理、竞态条件、内存泄漏、安全问题
• • 代码质量：重复代码、缺失错误处理、测试覆盖不足

置信度评分机制（0-100 分）：

• • 0：完全不可信（误报）
• • 25：有些可信（可能是误报）
• • 50：中等可信（真实但不重要）
• • 75：高度可信（重要且真实）
• • 100：绝对确定（频繁发生的高优先级问题）

关键规则：只报告置信度 ≥ 80 的问题，确保质量而非数量。

四、7 阶段工作流：Agent 协作的典范

阶段 1：Discovery（发现）

目标：理解要构建什么

操作：

1. 1. 创建 TODO 列表
2. 2. 如果需求不明确，询问用户：
• • 解决什么问题？
• • 功能应该做什么？
• • 有什么约束或需求？
3. 3. 总结理解并确认

阶段 2：Codebase Exploration（代码库探索）

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

操作：

1. 1. 并行启动 2-3 个 code-explorer agents，每个专注于不同方面：
• • “查找类似功能并追踪实现”
• • “映射架构和抽象层”
• • “分析相关功能的当前实现”
• • “识别 UI 模式、测试方法或扩展点”
2. 2. Agents 返回后，读取所有识别的关键文件
3. 3. 呈现全面的发现和模式总结

示例输出：

Found similar features:
- User authentication (src/auth/): Uses JWT tokens, middleware pattern
- Session management (src/session/): Redis-backed, 24hr expiry
- API security (src/api/middleware/): Rate limiting, CORS

Key files to understand:
- src/auth/AuthService.ts:45 - Core authentication logic
- src/middleware/authMiddleware.ts:12 - Request authentication

阶段 3：Clarifying Questions（澄清问题）

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

⚠️ 关键阶段：这是最重要的阶段之一，不可跳过。

操作：

1. 1. 审查代码库发现和原始需求
2. 2. 识别未明确的方面：
• • 边界情况
• • 错误处理
• • 集成点
• • 向后兼容性
• • 性能需求
3. 3. 以清晰、有组织的列表呈现所有问题
4. 4. 等待用户回答再进入架构设计

示例：

Before designing the architecture, I need to clarify:

1. OAuth provider: Which OAuth providers? (Google, GitHub, custom?)
2. User data: Store OAuth tokens or just user profile?
3. Existing auth: Replace current auth or add alongside?
4. Sessions: Integrate with existing session management?
5. Error handling: How to handle OAuth failures?

阶段 4：Architecture Design（架构设计）

目标：设计多种实现方案

操作：

1. 1. 并行启动 2-3 个 code-architect agents，每个有不同焦点：
• • 最小改动（最小变更，最大复用）
• • 清晰架构（可维护性，优雅抽象）
• • 务实平衡（速度 + 质量）
2. 2. 审查所有方案并形成自己的观点
3. 3. 呈现给用户：
• • 每个方案的简要总结
• • 权衡比较
• • 推荐方案及理由
• • 具体实现差异
4. 4. 询问用户偏好哪个方案

示例输出：

I've designed 3 approaches:

Approach 1: Minimal Changes
- Extend existing AuthService with OAuth methods
Pros: Fast, low risk
Cons: Couples OAuth to existing auth, harder to test

Approach 2: Clean Architecture
- New OAuthService with dedicated interface
Pros: Clean separation, testable, maintainable
Cons: More files, more refactoring

Recommendation: Approach 3 - Pragmatic Balance
- New OAuthProvider abstraction
- Integrate into existing AuthService
- Pros: Balanced complexity and cleanliness

Which approach would you like to use?

阶段 5：Implementation（实现）

目标：构建功能

⚠️ 重要：没有用户批准不启动

操作：

1. 1. 等待明确的用户批准
2. 2. 读取前面阶段识别的所有相关文件
3. 3. 按照选择的架构实现
4. 4. 严格遵守代码库约定
5. 5. 编写清晰、文档良好的代码
6. 6. 更新 TODO 进度

阶段 6：Quality Review（质量审查）

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

操作：

1. 1. 并行启动 3 个 code-reviewer agents，每个有不同焦点：
• • 简单性/DRY/优雅性
• • Bug/功能正确性
• • 项目约定/抽象
2. 2. 整合发现并识别最高严重性问题
3. 3. 呈现发现并询问用户想做什么（立即修复、稍后修复、按原样进行）
4. 4. 根据用户决策解决问题

示例输出：

Code Review Results:

High Priority Issues:
1. Missing error handling in OAuth callback (src/auth/oauth.ts:67) - Confidence: 95
2. Memory leak: OAuth state not cleaned up (src/auth/oauth.ts:89) - Confidence: 85

What would you like to do?
- Fix now
- Fix later
- Proceed as-is

阶段 7：Summary（总结）

目标：文档化已完成的工作

操作：

1. 1. 标记所有 TODO 完成
2. 2. 总结：
• • 构建了什么
• • 做出的关键决策
• • 修改的文件
• • 建议的后续步骤

五、插件系统核心概念展示

1. 模块化架构

每个组件都是独立文件，职责清晰：

• • commands/feature-dev.md：工作流编排
• • agents/code-explorer.md：代码理解
• • agents/code-architect.md：架构设计
• • agents/code-reviewer.md：质量保证

2. Agent 协作模式

工作流展示了如何让多个 Agent 并行工作：

• • 阶段 2：并行启动 2-3 个 code-explorer agents 探索不同方面
• • 阶段 4：并行启动 2-3 个 code-architect agents 设计不同方案
• • 阶段 6：并行启动 3 个 code-reviewer agents 审查不同维度

3. 工具权限配置

每个 Agent 在 frontmatter 中明确声明可用工具：

tools:Glob,Grep,LS,Read,NotebookRead,WebFetch,TodoWrite,WebSearch,KillShell,BashOutput

这确保 Agent 有完成其任务所需的精确工具集。

4. 模型选择

每个 Agent 可以选择不同的模型：

model:sonnet

对于复杂任务使用更强大的模型，对于简单任务使用更快模型。

5. 颜色标识

color:yellow/green/red

在 UI 中用颜色区分不同 Agent，提高可识别性。