mirror of
https://github.com/cexll/myclaude.git
synced 2026-02-04 02:20:42 +08:00
5a50131a13
- Create agents/ directory, move bmad, requirements, development-essentials - Remove docs/, hooks/, dev-workflow/ directories - Add npx support via github:cexll/myclaude - Add bin/cli.js with --update command for installed modules - Add package.json, skills/README.md, PLUGIN_README.md - Update all references across config.json, README, marketplace.json - Change default module from dev to do - Update CHANGELOG with all 59 tags BREAKING CHANGE: Directory structure changed, docs/hooks removed Generated with SWE-Agent.ai Co-Authored-By: SWE-Agent.ai <noreply@swe-agent.ai>
254 lines
7.0 KiB
Markdown
254 lines
7.0 KiB
Markdown
# Development Essentials - Core Development Commands
|
||
|
||
核心开发命令套件，提供日常开发所需的所有基础命令。无需工作流开销，直接执行开发任务。
|
||
|
||
## 📋 命令列表
|
||
|
||
### 1. `/ask` - 技术咨询
|
||
**用途**: 架构问题咨询和技术决策指导
|
||
**适用场景**: 需要架构建议、技术选型、系统设计方案时
|
||
|
||
**特点**:
|
||
- 四位架构顾问协同：系统设计师、技术策略师、可扩展性顾问、风险分析师
|
||
- 遵循 KISS、YAGNI、SOLID 原则
|
||
- 提供架构分析、设计建议、技术指导和实施策略
|
||
- **不生成代码**，专注于架构咨询
|
||
|
||
**使用示例**:
|
||
```bash
|
||
/ask "如何设计一个支持百万并发的消息队列系统？"
|
||
/ask "微服务架构中应该如何处理分布式事务？"
|
||
```
|
||
|
||
---
|
||
|
||
### 2. `/code` - 功能实现
|
||
**用途**: 直接实现新功能或特性
|
||
**适用场景**: 需要快速开发新功能时
|
||
|
||
**特点**:
|
||
- 四位开发专家协同：架构师、实现工程师、集成专家、代码审查员
|
||
- 渐进式开发，每步验证
|
||
- 包含完整的实现计划、代码实现、集成指南和测试策略
|
||
- 生成可运行的高质量代码
|
||
|
||
**使用示例**:
|
||
```bash
|
||
/code "实现JWT认证中间件"
|
||
/code "添加用户头像上传功能"
|
||
```
|
||
|
||
---
|
||
|
||
### 3. `/debug` - 系统调试
|
||
**用途**: 使用 UltraThink 方法系统性调试问题
|
||
**适用场景**: 遇到复杂bug或系统性问题时
|
||
|
||
**特点**:
|
||
- 四位专家协同：架构师、研究员、编码员、测试员
|
||
- UltraThink 反思阶段：综合所有洞察形成解决方案
|
||
- 生成5-7个假设，逐步缩减到1-2个最可能的原因
|
||
- 在实施修复前要求用户确认诊断结果
|
||
- 证据驱动的系统性问题分析
|
||
|
||
**使用示例**:
|
||
```bash
|
||
/debug "API响应时间突然增加10倍"
|
||
/debug "生产环境内存泄漏问题"
|
||
```
|
||
|
||
---
|
||
|
||
### 4. `/test` - 测试策略
|
||
**用途**: 设计和实现全面的测试策略
|
||
**适用场景**: 需要为组件或功能编写测试时
|
||
|
||
**特点**:
|
||
- 四位测试专家：测试架构师、单元测试专家、集成测试工程师、质量验证员
|
||
- 测试金字塔策略（单元/集成/端到端比例）
|
||
- 提供测试覆盖率分析和优先级建议
|
||
- 包含 CI/CD 集成计划
|
||
|
||
**使用示例**:
|
||
```bash
|
||
/test "用户认证模块"
|
||
/test "支付处理流程"
|
||
```
|
||
|
||
---
|
||
|
||
### 5. `/optimize` - 性能优化
|
||
**用途**: 识别和优化性能瓶颈
|
||
**适用场景**: 系统存在性能问题或需要提升性能时
|
||
|
||
**特点**:
|
||
- 四位优化专家：性能分析师、算法工程师、资源管理员、可扩展性架构师
|
||
- 建立性能基线和量化指标
|
||
- 优化算法复杂度、内存使用、I/O操作
|
||
- 设计水平扩展和并发处理方案
|
||
|
||
**使用示例**:
|
||
```bash
|
||
/optimize "数据库查询性能"
|
||
/optimize "API响应时间优化到200ms以内"
|
||
```
|
||
|
||
---
|
||
|
||
### 6. `/review` - 代码审查
|
||
**用途**: 全方位代码质量审查
|
||
**适用场景**: 需要审查代码质量、安全性和架构设计时
|
||
|
||
**特点**:
|
||
- 四位审查专家：质量审计员、安全分析师、性能审查员、架构评估员
|
||
- 多维度审查：可读性、安全性、性能、架构设计
|
||
- 提供优先级分类的改进建议
|
||
- 包含具体代码示例和重构建议
|
||
|
||
**使用示例**:
|
||
```bash
|
||
/review "src/auth/middleware.ts"
|
||
/review "支付模块代码"
|
||
```
|
||
|
||
---
|
||
|
||
### 7. `/bugfix` - Bug修复
|
||
**用途**: 快速定位和修复Bug
|
||
**适用场景**: 需要修复已知Bug时
|
||
|
||
**特点**:
|
||
- 专注于快速修复
|
||
- 包含验证流程
|
||
- 确保修复不引入新问题
|
||
|
||
**使用示例**:
|
||
```bash
|
||
/bugfix "登录失败后session未清理"
|
||
/bugfix "订单状态更新不及时"
|
||
```
|
||
|
||
---
|
||
|
||
### 8. `/refactor` - 代码重构
|
||
**用途**: 改进代码结构和可维护性
|
||
**适用场景**: 代码质量下降或需要优化代码结构时
|
||
|
||
**特点**:
|
||
- 保持功能不变
|
||
- 提升代码质量和可维护性
|
||
- 遵循设计模式和最佳实践
|
||
|
||
**使用示例**:
|
||
```bash
|
||
/refactor "将用户管理模块拆分为独立服务"
|
||
/refactor "优化支付流程代码结构"
|
||
```
|
||
|
||
---
|
||
|
||
### 9. `/docs` - 文档生成
|
||
**用途**: 生成项目文档和API文档
|
||
**适用场景**: 需要为代码或API生成文档时
|
||
|
||
**特点**:
|
||
- 自动分析代码结构
|
||
- 生成清晰的文档
|
||
- 包含使用示例
|
||
|
||
**使用示例**:
|
||
```bash
|
||
/docs "API接口文档"
|
||
/docs "为认证模块生成开发者文档"
|
||
```
|
||
|
||
---
|
||
|
||
### 10. `/think` - 深度分析
|
||
**用途**: 对复杂问题进行深度思考和分析
|
||
**适用场景**: 需要全面分析复杂技术问题时
|
||
|
||
**特点**:
|
||
- 系统性思考框架
|
||
- 多角度问题分析
|
||
- 提供深入见解
|
||
|
||
**使用示例**:
|
||
```bash
|
||
/think "如何设计一个高可用的分布式系统？"
|
||
/think "微服务拆分的最佳实践是什么？"
|
||
```
|
||
|
||
---
|
||
|
||
### 11. `/enhance-prompt` - 提示词增强 🆕
|
||
**用途**: 优化和增强用户提供的指令
|
||
**适用场景**: 需要改进模糊或不清晰的指令时
|
||
|
||
**特点**:
|
||
- 自动分析指令上下文
|
||
- 消除歧义，提高清晰度
|
||
- 修正错误并提高具体性
|
||
- 立即返回增强后的提示词
|
||
- 保留代码块等特殊格式
|
||
|
||
**输出格式**:
|
||
```
|
||
### Here is an enhanced version of the original instruction that is more specific and clear:
|
||
<enhanced-prompt>增强后的提示词</enhanced-prompt>
|
||
```
|
||
|
||
**使用示例**:
|
||
```bash
|
||
/enhance-prompt "帮我做一个登录功能"
|
||
/enhance-prompt "优化一下这个API"
|
||
```
|
||
|
||
---
|
||
|
||
## 🎯 命令选择指南
|
||
|
||
| 需求场景 | 推荐命令 | 说明 |
|
||
|---------|---------|------|
|
||
| 需要架构建议 | `/ask` | 不生成代码，专注咨询 |
|
||
| 实现新功能 | `/code` | 完整的功能实现流程 |
|
||
| 调试复杂问题 | `/debug` | UltraThink系统性调试 |
|
||
| 编写测试 | `/test` | 全面的测试策略 |
|
||
| 性能优化 | `/optimize` | 性能瓶颈分析和优化 |
|
||
| 代码审查 | `/review` | 多维度质量审查 |
|
||
| 修复Bug | `/bugfix` | 快速定位和修复 |
|
||
| 重构代码 | `/refactor` | 提升代码质量 |
|
||
| 生成文档 | `/docs` | API和开发者文档 |
|
||
| 深度思考 | `/think` | 复杂问题分析 |
|
||
| 优化指令 | `/enhance-prompt` | 提示词增强 |
|
||
|
||
## 🔧 代理列表
|
||
|
||
Development Essentials 模块包含以下专用代理：
|
||
|
||
- `code` - 代码实现代理
|
||
- `bugfix` - Bug修复代理
|
||
- `bugfix-verify` - Bug验证代理
|
||
- `code-optimize` - 代码优化代理
|
||
- `debug` - 调试分析代理
|
||
- `develop` - 通用开发代理
|
||
|
||
## 📖 使用原则
|
||
|
||
1. **直接执行**: 无需工作流开销，直接运行命令
|
||
2. **专注单一任务**: 每个命令聚焦特定开发任务
|
||
3. **质量优先**: 所有命令都包含质量验证环节
|
||
4. **实用主义**: KISS/YAGNI/DRY 原则贯穿始终
|
||
5. **上下文感知**: 自动理解项目结构和编码规范
|
||
|
||
## 🔗 相关文档
|
||
|
||
- [主文档](../README.md) - 项目总览
|
||
- [BMAD工作流](../agents/bmad/BMAD-WORKFLOW.md) - 完整敏捷流程
|
||
- [Requirements工作流](../agents/requirements/REQUIREMENTS-WORKFLOW.md) - 轻量级开发流程
|
||
- [插件系统](../PLUGIN_README.md) - 插件安装和管理
|
||
|
||
---
|
||
|
||
**提示**: 这些命令可以单独使用，也可以组合使用。例如：`/code` → `/test` → `/review` → `/optimize` 构成一个完整的开发周期。
|