783 lines
24 KiB
Markdown
783 lines
24 KiB
Markdown
# SuperClaude 命令指南 🛠️
|
||
|
||
## 💡 不要想太多 - SuperClaude 试图提供帮助
|
||
|
||
**关于这 17 个命令的真相**：您不需要记住它们。只需从 `/sc:analyze` 或 `/sc:implement` 开始，看看会发生什么！
|
||
|
||
**通常它是这样工作的：**
|
||
- 在 Claude Code 中输入 `/` → 查看可用命令
|
||
- 使用基本命令如 `/sc:analyze`、`/sc:build`、`/sc:improve`
|
||
- **SuperClaude 尝试为每种情况选择有用的工具和专家**
|
||
- 当您适应时，更多命令会变得有用
|
||
|
||
**自动激活相当 neat** 🪄 - SuperClaude 尝试检测您想要做什么并激活相关专家（安全专家、性能优化器等），而无需您管理。通常效果很好！😊
|
||
|
||
---
|
||
|
||
## 快速"直接试试这些"列表 🚀
|
||
|
||
**从这里开始**（无需阅读）：
|
||
```bash
|
||
/sc:index # 查看可用内容
|
||
/sc:analyze src/ # 尝试智能分析您的代码
|
||
/sc:workflow feature-100-prd.md # 从 PRD 创建分步实施工作流程
|
||
/sc:implement user-auth # 创建功能和组件（替换 v2 的 /build）
|
||
/sc:build # 尝试智能项目构建
|
||
/sc:improve messy-file.js # 尝试清理代码
|
||
/sc:troubleshoot "error" # 尝试帮助解决问题
|
||
```
|
||
|
||
**说实话，这足以开始。** 当您对其他可用工具感到好奇时，下面的所有内容都在这里。🛠️
|
||
|
||
---
|
||
|
||
SuperClaude 全部 16 个斜杠命令的实用指南。我们将诚实地说出哪些工作得好，哪些仍然有粗糙边缘。
|
||
|
||
## 快速参考 📋
|
||
|
||
*（您真的不需要记住这个 - 只需选择听起来有用的）*
|
||
|
||
| 命令 | 目的 | 自动激活 | 最适合 |
|
||
|---------|---------|-----------------|----------|
|
||
| `/sc:analyze` | 智能代码分析 | 安全/性能专家 | 查找问题、理解代码库 |
|
||
| `/sc:build` | 智能构建 | 前端/后端专家 | 编译、打包、部署准备 |
|
||
| `/sc:implement` | 功能实现 | 领域特定专家 | 创建功能、组件、API、服务 |
|
||
| `/sc:improve` | 自动代码清理 | 质量专家 | 重构、优化、质量修复 |
|
||
| `/sc:troubleshoot` | 问题调查 | 调试专家 | 调试、问题调查 |
|
||
| `/sc:test` | 智能测试 | QA 专家 | 运行测试、覆盖率分析 |
|
||
| `/sc:document` | 自动文档 | 写作专家 | README 文件、代码注释、指南 |
|
||
| `/sc:git` | 增强 git 工作流程 | DevOps 专家 | 智能提交、分支管理 |
|
||
| `/sc:design` | 系统设计帮助 | 架构专家 | 架构规划、API 设计 |
|
||
| `/sc:explain` | 学习助手 | 教学专家 | 学习概念、理解代码 |
|
||
| `/sc:cleanup` | 减少债务 | 重构专家 | 删除死代码、组织文件 |
|
||
| `/sc:load` | 上下文理解 | 分析专家 | 项目分析、代码库理解 |
|
||
| `/sc:estimate` | 智能估算 | 规划专家 | 时间/精力规划、复杂性分析 |
|
||
| `/sc:spawn` | 复杂工作流程 | 编排系统 | 多步操作、工作流程自动化 |
|
||
| `/sc:task` | 项目管理 | 规划系统 | 长期功能规划、任务跟踪 |
|
||
| `/sc:workflow` | 实施规划 | 工作流程系统 | 从 PRD 创建分步工作流程 |
|
||
| `/sc:index` | 命令导航 | 帮助系统 | 为您的任务找到正确的命令 |
|
||
|
||
**专业提示**：只需尝试听起来有用的命令。SuperClaude 通常会为每种情况尝试激活有用的专家和工具！🎯
|
||
|
||
## 开发命令 🔨
|
||
|
||
### `/workflow` - 工作流程实施生成器 🗺️
|
||
**功能**：分析 PRD 和功能要求，创建全面的分步实施工作流程。
|
||
|
||
**有用的部分**：获取您的 PRD 并将其分解为结构化的实施计划，包含专家指导、依赖映射和任务编排！🎯
|
||
|
||
**何时使用**：
|
||
- 从 PRD 或规范开始新功能
|
||
- 需要清晰的实施路线图
|
||
- 希望获得实施策略的专家指导
|
||
- 规划具有多个依赖项的复杂功能
|
||
|
||
**神奇之处**：根据您的功能要求自动激活适当的专家角色（架构师、安全、前端、后端）和 MCP 服务器（Context7 用于模式，Sequential 用于复杂分析）。
|
||
|
||
**示例**：
|
||
```bash
|
||
/sc:workflow docs/feature-100-prd.md --strategy systematic --c7 --sequential
|
||
/sc:workflow "user authentication system" --persona security --output detailed
|
||
/sc:workflow payment-api --strategy mvp --risks --dependencies
|
||
```
|
||
|
||
**您得到的**：
|
||
- **路线图格式**：基于阶段的时间表实施计划
|
||
- **任务格式**：组织化的史诗、故事和可操作任务
|
||
- **详细格式**：带时间估算的分步说明
|
||
- **风险评估**：潜在问题和缓解策略
|
||
- **依赖映射**：内部和外部依赖
|
||
- **专家指导**：领域特定的最佳实践和模式
|
||
|
||
### `/implement` - 功能实施
|
||
**功能**：通过智能专家激活实现功能、组件和功能。
|
||
|
||
**有用的部分**：SuperClaude 根据您正在实现的内容自动激活正确的专家（前端、后端、安全）和工具！🎯
|
||
|
||
**何时使用**：
|
||
- 创建新功能或组件（替换 v2 的 `/build` 功能）
|
||
- 实现 API、服务或模块
|
||
- 使用现代框架构建 UI 组件
|
||
- 开发业务逻辑和集成
|
||
|
||
**基本语法**：
|
||
```bash
|
||
/sc:implement user authentication system # 实现完整功能
|
||
/sc:implement --type component LoginForm # 创建特定组件
|
||
/sc:implement --type api user-management # 构建 API 端点
|
||
/sc:implement --framework react dashboard # 特定于框架的实施
|
||
```
|
||
|
||
**有用的标志**：
|
||
- `--type component|api|service|feature|module` - 实施类型
|
||
- `--framework react|vue|express|django|etc` - 目标框架
|
||
- `--safe` - 保守的实施方法
|
||
- `--iterative` - 带验证的分步开发
|
||
- `--with-tests` - 包含测试实施
|
||
- `--documentation` - 随代码生成文档
|
||
|
||
**实际示例**：
|
||
```bash
|
||
/sc:implement user authentication --type feature --with-tests
|
||
/sc:implement dashboard component --type component --framework react
|
||
/sc:implement REST API for orders --type api --safe
|
||
/sc:implement payment processing --type service --iterative
|
||
/sc:implement search functionality --framework vue --documentation
|
||
```
|
||
|
||
**自动激活模式**：
|
||
- **前端**：UI 组件、React/Vue/Angular → 前端角色 + Magic MCP
|
||
- **后端**：API、服务、数据库 → 后端角色 + Context7
|
||
- **安全**：身份验证、支付、敏感数据 → 安全角色 + 验证
|
||
- **复杂功能**：多步实施 → Sequential MCP + 架构师角色
|
||
|
||
**注意事项**：
|
||
- 指定 `--type` 以获得更好的结果（组件 vs 服务 vs 功能）
|
||
- 使用特定技术栈时使用 `--framework`
|
||
- 生产代码尝试 `--safe` 或复杂功能尝试 `--iterative`
|
||
- 记住：这替换了 v2 的 `/build` 用于实际代码实施
|
||
|
||
---
|
||
|
||
### `/build` - 项目构建
|
||
**功能**：构建、编译和打包项目，具有智能错误处理。
|
||
|
||
**简单方法**：只需输入 `/sc:build`，SuperClaude 尝试弄清楚您的构建系统！🎯
|
||
|
||
**何时使用**：
|
||
- 您需要编译/捆绑项目（只需尝试 `/sc:build`）
|
||
- 构建过程失败，您想要调试帮助
|
||
- 设置构建优化（它尝试检测您需要什么）
|
||
- 为部署做准备
|
||
|
||
**基本语法**：
|
||
```bash
|
||
/sc:build # 构建当前项目
|
||
/sc:build --type prod # 生产构建
|
||
/sc:build --clean # 清理构建（删除旧构件）
|
||
/sc:build --optimize # 启用优化
|
||
/sc:build src/ # 构建特定目录
|
||
```
|
||
|
||
**有用的标志**：
|
||
- `--type dev|prod|test` - 构建类型
|
||
- `--clean` - 构建前清理
|
||
- `--optimize` - 启用构建优化
|
||
- `--verbose` - 显示详细构建输出
|
||
|
||
**实际示例**：
|
||
```bash
|
||
/sc:build --type prod --optimize # 带优化的生产构建
|
||
/sc:build --clean --verbose # 带详细输出的清理构建
|
||
/sc:build src/components # 仅构建组件文件夹
|
||
```
|
||
|
||
**注意事项**：
|
||
- 与常见构建工具（npm、webpack 等）配合使用效果最好
|
||
- 可能在非常定制的构建设置中遇到困难
|
||
- 检查您的构建工具在 PATH 中
|
||
|
||
---
|
||
|
||
### `/design` - 系统和组件设计
|
||
**功能**：创建系统架构、API 设计和组件规范。
|
||
|
||
**何时使用**：
|
||
- 规划新功能或系统
|
||
- 需要 API 或数据库设计
|
||
- 创建组件架构
|
||
- 记录系统关系
|
||
|
||
**基本语法**：
|
||
```bash
|
||
/sc:design user-auth-system # 设计用户认证系统
|
||
/sc:design --type api auth # 仅设计 API 部分
|
||
/sc:design --format spec payment # 创建正式规范
|
||
```
|
||
|
||
**有用的标志**：
|
||
- `--type architecture|api|component|database` - 设计焦点
|
||
- `--format diagram|spec|code` - 输出格式
|
||
- `--iterative` - 通过迭代优化设计
|
||
|
||
**实际示例**：
|
||
```bash
|
||
/sc:design --type api user-management # 设计用户管理 API
|
||
/sc:design --format spec chat-system # 创建聊天系统规范
|
||
/sc:design --type database ecommerce # 设计数据库模式
|
||
```
|
||
|
||
**注意事项**：
|
||
- 更多是概念性的而非代码生成
|
||
- 输出质量取决于您描述需求的清晰程度
|
||
- 适合规划阶段，不适合实施细节
|
||
|
||
## 分析命令 🔍
|
||
|
||
### `/analyze` - 代码分析
|
||
**功能**：对代码质量、安全性、性能和架构进行全面分析。
|
||
|
||
**有用的部分**：SuperClaude 尝试检测您需要什么类型的分析，通常会选择相关专家！🔍
|
||
|
||
**何时使用**：
|
||
- 理解不熟悉的代码库（只需将其指向任何文件夹）
|
||
- 查找安全漏洞（安全专家通常会介入）
|
||
- 性能瓶颈搜索（性能专家通常会帮助）
|
||
- 代码质量评估（质量专家通常会接管）
|
||
|
||
**基本语法**：
|
||
```bash
|
||
/sc:analyze src/ # 分析整个 src 目录
|
||
/sc:analyze --focus security # 关注安全问题
|
||
/sc:analyze --depth deep app.js # 深度分析特定文件
|
||
```
|
||
|
||
**有用的标志**：
|
||
- `--focus quality|security|performance|architecture` - 分析焦点
|
||
- `--depth quick|deep` - 分析彻底性
|
||
- `--format text|json|report` - 输出格式
|
||
|
||
**实际示例**：
|
||
```bash
|
||
/sc:analyze --focus security --depth deep # 深度安全分析
|
||
/sc:analyze --focus performance src/api/ # API 性能分析
|
||
/sc:analyze --format report . # 生成分析报告
|
||
```
|
||
|
||
**注意事项**：
|
||
- 在大型代码库上可能需要一段时间
|
||
- 安全分析相当好，性能分析因情况而异
|
||
- 与常见语言（JS、Python 等）配合使用效果最好
|
||
|
||
---
|
||
|
||
### `/troubleshoot` - 问题调查
|
||
**功能**：系统调试和问题调查。
|
||
|
||
**何时使用**：
|
||
- 某些东西坏了，您不确定为什么
|
||
- 需要系统调试方法
|
||
- 错误消息令人困惑
|
||
- 性能问题调查
|
||
|
||
**基本语法**：
|
||
```bash
|
||
/sc:troubleshoot "login not working" # 调查登录问题
|
||
/sc:troubleshoot --logs error.log # 分析错误日志
|
||
/sc:troubleshoot performance # 性能故障排除
|
||
```
|
||
|
||
**有用的标志**：
|
||
- `--logs <file>` - 包含日志文件分析
|
||
- `--systematic` - 使用结构化调试方法
|
||
- `--focus network|database|frontend` - 焦点区域
|
||
|
||
**实际示例**：
|
||
```bash
|
||
/sc:troubleshoot "API returning 500" --logs server.log
|
||
/sc:troubleshoot --focus database "slow queries"
|
||
/sc:troubleshoot "build failing" --systematic
|
||
```
|
||
|
||
**注意事项**：
|
||
- 在特定错误描述下效果更好
|
||
- 尽可能包含相关错误消息和日志
|
||
- 可能首先建议显而易见的事情（这通常很好！）
|
||
|
||
---
|
||
|
||
### `/explain` - 教育解释
|
||
**功能**：以教育方式解释代码、概念和技术。
|
||
|
||
**何时使用**：
|
||
- 学习新技术或模式
|
||
- 理解复杂代码
|
||
- 需要为团队成员提供清晰解释
|
||
- 记录棘手概念
|
||
|
||
**基本语法**：
|
||
```bash
|
||
/sc:explain async/await # 解释 async/await 概念
|
||
/sc:explain --code src/utils.js # 解释特定代码文件
|
||
/sc:explain --beginner React hooks # 适合初学者的解释
|
||
```
|
||
|
||
**有用的标志**：
|
||
- `--beginner` - 更简单的解释
|
||
- `--advanced` - 技术深度
|
||
- `--code <file>` - 解释特定代码
|
||
- `--examples` - 包含实际示例
|
||
|
||
**实际示例**：
|
||
```bash
|
||
/sc:explain --beginner "what is REST API"
|
||
/sc:explain --code src/auth.js --advanced
|
||
/sc:explain --examples "React context patterns"
|
||
```
|
||
|
||
**注意事项**：
|
||
- 对于知名概念很棒，对于非常小众的话题可能困难
|
||
- 比模糊的"解释这个代码库"更适合具体问题
|
||
- 包含您经验水平的背景
|
||
|
||
## 质量命令 ✨
|
||
|
||
### `/improve` - 代码增强
|
||
**功能**：对代码质量、性能和可维护性进行系统性改进。
|
||
|
||
**何时使用**：
|
||
- 重构混乱的代码
|
||
- 性能优化
|
||
- 应用最佳实践
|
||
- 现代化旧代码
|
||
|
||
**基本语法**：
|
||
```bash
|
||
/sc:improve src/legacy/ # 改进遗留代码
|
||
/sc:improve --type performance # 关注性能
|
||
/sc:improve --safe src/utils.js # 仅安全、低风险改进
|
||
```
|
||
|
||
**有用的标志**：
|
||
- `--type quality|performance|maintainability|style` - 改进焦点
|
||
- `--safe` - 仅应用低风险更改
|
||
- `--preview` - 显示将要更改的内容而不执行
|
||
|
||
**实际示例**：
|
||
```bash
|
||
/sc:improve --type performance --safe src/api/
|
||
/sc:improve --preview src/components/LegacyComponent.js
|
||
/sc:improve --type style . --safe
|
||
```
|
||
|
||
**注意事项**：
|
||
- 始终首先使用 `--preview` 查看它想要更改什么
|
||
- `--safe` 是您的朋友 - 防止风险重构
|
||
- 在较小的文件/模块上比在整个代码库上效果更好
|
||
|
||
---
|
||
|
||
### `/cleanup` - 技术债务减少
|
||
**功能**：删除死代码、未使用的导入并组织文件结构。
|
||
|
||
**何时使用**：
|
||
- 代码库感觉杂乱
|
||
- 大量未使用的导入/变量
|
||
- 文件组织混乱
|
||
- 重大重构之前
|
||
|
||
**基本语法**：
|
||
```bash
|
||
/sc:cleanup src/ # 清理 src 目录
|
||
/sc:cleanup --dead-code # 关注删除死代码
|
||
/sc:cleanup --imports package.js # 清理特定文件中的导入
|
||
```
|
||
|
||
**有用的标志**：
|
||
- `--dead-code` - 删除未使用的代码
|
||
- `--imports` - 清理导入语句
|
||
- `--files` - 重新组织文件结构
|
||
- `--safe` - 仅保守清理
|
||
|
||
**实际示例**：
|
||
```bash
|
||
/sc:cleanup --dead-code --safe src/utils/
|
||
/sc:cleanup --imports src/components/
|
||
/sc:cleanup --files . --safe
|
||
```
|
||
|
||
**注意事项**：
|
||
- 可能激进 - 始终仔细审查更改
|
||
- 可能无法捕获所有死代码（特别是动态导入）
|
||
- 最好在较小部分而不是整个项目上运行
|
||
|
||
---
|
||
|
||
### `/test` - 测试和质量保证
|
||
**功能**：运行测试、生成覆盖率报告并维护测试质量。
|
||
|
||
**何时使用**：
|
||
- 运行测试套件
|
||
- 检查测试覆盖率
|
||
- 生成测试报告
|
||
- 设置持续测试
|
||
|
||
**基本语法**：
|
||
```bash
|
||
/sc:test # 运行所有测试
|
||
/sc:test --type unit # 仅运行单元测试
|
||
/sc:test --coverage # 生成覆盖率报告
|
||
/sc:test --watch src/ # 开发观察模式
|
||
```
|
||
|
||
**有用的标志**：
|
||
- `--type unit|integration|e2e|all` - 测试类型
|
||
- `--coverage` - 生成覆盖率报告
|
||
- `--watch` - 在观察模式下运行测试
|
||
- `--fix` - 尝试自动修复失败的测试
|
||
|
||
**实际示例**：
|
||
```bash
|
||
/sc:test --type unit --coverage
|
||
/sc:test --watch src/components/
|
||
/sc:test --type e2e --fix
|
||
```
|
||
|
||
**注意事项**：
|
||
- 需要您的测试框架正确配置
|
||
- 覆盖率报告取决于您现有的测试设置
|
||
- `--fix` 是实验性的 - 审查它更改的内容
|
||
|
||
## 文档命令 📝
|
||
|
||
### `/document` - 专注文档
|
||
**功能**：为特定组件、函数或功能创建文档。
|
||
|
||
**何时使用**：
|
||
- 需要 README 文件
|
||
- 编写 API 文档
|
||
- 添加代码注释
|
||
- 创建用户指南
|
||
|
||
**基本语法**：
|
||
```bash
|
||
/sc:document src/api/auth.js # 记录认证模块
|
||
/sc:document --type api # API 文档
|
||
/sc:document --style brief README # 简短 README 文件
|
||
```
|
||
|
||
**有用的标志**：
|
||
- `--type inline|external|api|guide` - 文档类型
|
||
- `--style brief|detailed` - 详细程度
|
||
- `--template` - 使用特定文档模板
|
||
|
||
**实际示例**：
|
||
```bash
|
||
/sc:document --type api src/controllers/
|
||
/sc:document --style detailed --type guide user-onboarding
|
||
/sc:document --type inline src/utils/helpers.js
|
||
```
|
||
|
||
**注意事项**：
|
||
- 与整个项目相比，更适合特定文件/函数
|
||
- 质量取决于代码结构化程度
|
||
- 可能需要一些编辑以匹配您项目的文档风格
|
||
|
||
## 项目管理命令 📊
|
||
|
||
### `/estimate` - 项目估算
|
||
**功能**：估算开发任务的时间、精力和复杂性。
|
||
|
||
**何时使用**：
|
||
- 规划新功能
|
||
- 冲刺规划
|
||
- 理解项目复杂性
|
||
- 资源分配
|
||
|
||
**基本语法**：
|
||
```bash
|
||
/sc:estimate "add user authentication" # 估算身份验证功能
|
||
/sc:estimate --detailed shopping-cart # 详细分解
|
||
/sc:estimate --complexity user-dashboard # 复杂性分析
|
||
```
|
||
|
||
**有用的标志**：
|
||
- `--detailed` - 任务详细分解
|
||
- `--complexity` - 关注技术复杂性
|
||
- `--team-size <n>` - 在估算中考虑团队规模
|
||
|
||
**实际示例**：
|
||
```bash
|
||
/sc:estimate --detailed "implement payment system"
|
||
/sc:estimate --complexity --team-size 3 "migrate to microservices"
|
||
/sc:estimate "add real-time chat" --detailed
|
||
```
|
||
|
||
**注意事项**：
|
||
- 估算是粗略的 - 用作起点，而非金科玉律
|
||
- 在清晰、具体的功能描述下效果更好
|
||
- 考虑您团队在技术栈方面的经验
|
||
|
||
---
|
||
|
||
### `/task` - 长期项目管理
|
||
**功能**：管理复杂的多会话开发任务和功能。
|
||
|
||
**何时使用**：
|
||
- 规划需要数天/数周的功能
|
||
- 分解大型项目
|
||
- 跨会话跟踪进度
|
||
- 协调团队工作
|
||
|
||
**基本语法**：
|
||
```bash
|
||
/sc:task create "implement user dashboard" # 创建新任务
|
||
/sc:task status # 检查任务状态
|
||
/sc:task breakdown "payment integration" # 分解为子任务
|
||
```
|
||
|
||
**有用的标志**：
|
||
- `create` - 创建新的长期任务
|
||
- `status` - 检查当前任务状态
|
||
- `breakdown` - 将大任务分解为小任务
|
||
- `--priority high|medium|low` - 设置任务优先级
|
||
|
||
**实际示例**：
|
||
```bash
|
||
/sc:task create "migrate from REST to GraphQL" --priority high
|
||
/sc:task breakdown "e-commerce checkout flow"
|
||
/sc:task status
|
||
```
|
||
|
||
**注意事项**：
|
||
- 仍在实验中 - 并不总是能可靠地跨会话持久化 😅
|
||
- 更适合规划而非实际项目管理
|
||
- 当您对需求具体时效果最好
|
||
|
||
---
|
||
|
||
### `/spawn` - 复杂操作编排
|
||
**功能**：协调复杂的多步操作和工作流程。
|
||
|
||
**何时使用**：
|
||
- 涉及多个工具/系统的操作
|
||
- 协调并行工作流程
|
||
- 复杂部署流程
|
||
- 多阶段数据处理
|
||
|
||
**基本语法**：
|
||
```bash
|
||
/sc:spawn deploy-pipeline # 编排部署
|
||
/sc:spawn --parallel migrate-data # 并行数据迁移
|
||
/sc:spawn setup-dev-environment # 复杂环境设置
|
||
```
|
||
|
||
**有用的标志**：
|
||
- `--parallel` - 可能时并行运行操作
|
||
- `--sequential` - 强制顺序执行
|
||
- `--monitor` - 监控操作进度
|
||
|
||
**实际示例**：
|
||
```bash
|
||
/sc:spawn --parallel "test and deploy to staging"
|
||
/sc:spawn setup-ci-cd --monitor
|
||
/sc:spawn --sequential database-migration
|
||
```
|
||
|
||
**注意事项**：
|
||
- 最复杂的命令 - 预期一些粗糙边缘
|
||
- 对于定义明确的工作流程比临时操作更好
|
||
- 可能需要多次迭代才能正确
|
||
|
||
## 版本控制命令 🔄
|
||
|
||
### `/git` - 增强 Git 操作
|
||
**功能**：Git 操作具有智能提交消息和工作流程优化。
|
||
|
||
**何时使用**：
|
||
- 制作具有更好消息的提交
|
||
- 分支管理
|
||
- 复杂 git 工作流程
|
||
- Git 故障排除
|
||
|
||
**基本语法**：
|
||
```bash
|
||
/sc:git commit # 智能提交，自动生成消息
|
||
/sc:git --smart-commit add . # 添加并智能提交
|
||
/sc:git branch feature/new-auth # 创建并切换到新分支
|
||
```
|
||
|
||
**有用的标志**：
|
||
- `--smart-commit` - 生成智能提交消息
|
||
- `--branch-strategy` - 应用分支命名约定
|
||
- `--interactive` - 复杂操作的交互模式
|
||
|
||
**实际示例**：
|
||
```bash
|
||
/sc:git --smart-commit "fixed login bug"
|
||
/sc:git branch feature/user-dashboard --branch-strategy
|
||
/sc:git merge develop --interactive
|
||
```
|
||
|
||
**注意事项**：
|
||
- 智能提交消息相当不错，但请审查它们
|
||
- 假设您遵循常见 git 工作流程
|
||
- 不会修复不良 git 习惯 - 只是让它们更容易
|
||
|
||
## 实用命令 🔧
|
||
|
||
### `/index` - 命令导航
|
||
**功能**：帮助您为任务找到正确的命令。
|
||
|
||
**何时使用**：
|
||
- 不确定使用哪个命令
|
||
- 探索可用命令
|
||
- 了解命令能力
|
||
|
||
**基本语法**：
|
||
```bash
|
||
/sc:index # 列出所有命令
|
||
/sc:index testing # 查找与测试相关的命令
|
||
/sc:index --category analysis # 分析类别中的命令
|
||
```
|
||
|
||
**有用的标志**：
|
||
- `--category <cat>` - 按命令类别过滤
|
||
- `--search <term>` - 搜索命令描述
|
||
|
||
**实际示例**：
|
||
```bash
|
||
/sc:index --search "performance"
|
||
/sc:index --category quality
|
||
/sc:index git
|
||
```
|
||
|
||
**注意事项**：
|
||
- 简单但对发现有用
|
||
- 比尝试记住所有 16 个命令更好
|
||
|
||
---
|
||
|
||
### `/load` - 项目上下文加载
|
||
**功能**：加载和分析项目上下文以获得更好理解。
|
||
|
||
**何时使用**：
|
||
- 开始不熟悉项目上的工作
|
||
- 需要理解项目结构
|
||
- 进行重大更改之前
|
||
- 团队成员入职
|
||
|
||
**基本语法**：
|
||
```bash
|
||
/sc:load # 加载当前项目上下文
|
||
/sc:load src/ # 加载特定目录上下文
|
||
/sc:load --deep # 深度分析项目结构
|
||
```
|
||
|
||
**有用的标志**：
|
||
- `--deep` - 全面的项目分析
|
||
- `--focus <area>` - 关注特定项目区域
|
||
- `--summary` - 生成项目摘要
|
||
|
||
**实际示例**：
|
||
```bash
|
||
/sc:load --deep --summary
|
||
/sc:load src/components/ --focus architecture
|
||
/sc:load . --focus dependencies
|
||
```
|
||
|
||
**注意事项**：
|
||
- 在大型项目上可能需要时间
|
||
- 在项目开始时比开发期间更有用
|
||
- 有助于入职，但不能替代良好的文档
|
||
|
||
## 命令提示和模式 💡
|
||
|
||
### 有效标志组合
|
||
```bash
|
||
# 安全改进工作流程
|
||
/sc:improve --preview src/component.js # 查看会更改什么
|
||
/sc:improve --safe src/component.js # 仅应用安全更改
|
||
|
||
# 全面的分析
|
||
/sc:analyze --focus security --depth deep
|
||
/sc:test --coverage
|
||
/sc:document --type api
|
||
|
||
# 智能 git 工作流程
|
||
/sc:git add .
|
||
/sc:git --smart-commit --branch-strategy
|
||
|
||
# 项目理解工作流程
|
||
/sc:load --deep --summary
|
||
/sc:analyze --focus architecture
|
||
/sc:document --type guide
|
||
```
|
||
|
||
### 常见工作流程
|
||
|
||
**新项目入职**：
|
||
```bash
|
||
/sc:load --deep --summary
|
||
/sc:analyze --focus architecture
|
||
/sc:test --coverage
|
||
/sc:document README
|
||
```
|
||
|
||
**错误调查**：
|
||
```bash
|
||
/sc:troubleshoot "specific error message" --logs
|
||
/sc:analyze --focus security
|
||
/sc:test --type unit affected-component
|
||
```
|
||
|
||
**代码质量改进**：
|
||
```bash
|
||
/sc:analyze --focus quality
|
||
/sc:improve --preview src/
|
||
/sc:cleanup --safe
|
||
/sc:test --coverage
|
||
```
|
||
|
||
**部署前检查清单**：
|
||
```bash
|
||
/sc:test --type all --coverage
|
||
/sc:analyze --focus security
|
||
/sc:build --type prod --optimize
|
||
/sc:git --smart-commit
|
||
```
|
||
|
||
### 故障排除命令问题
|
||
|
||
**命令未按预期工作？**
|
||
- 尝试添加 `--help` 查看所有选项
|
||
- 可用时使用 `--preview` 或 `--safe` 标志
|
||
- 从较小范围开始（单个文件 vs 整个项目）
|
||
|
||
**分析花费时间太长？**
|
||
- 使用 `--focus` 缩小范围
|
||
- 尝试 `--depth quick` 而不是深度分析
|
||
- 首先分析较小的目录
|
||
|
||
**构建/测试命令失败？**
|
||
- 确保您的工具在 PATH 中
|
||
- 检查配置文件在预期位置
|
||
- 首先尝试直接运行底层命令
|
||
|
||
**不确定使用哪个命令？**
|
||
- 使用 `/index` 浏览可用命令
|
||
- 查看上面的快速参考表
|
||
- 首先尝试最具体的命令，然后是更宽泛的命令
|
||
|
||
---
|
||
|
||
## 最后说明 📝
|
||
|
||
**关于这些命令的真相** 💯：
|
||
- **只需尝试它们** - 您无需首先研究此指南
|
||
- **从基础开始** - `/analyze`、`/build`、`/improve` 涵盖大多数需求
|
||
- **让自动激活工作** - SuperClaude 通常会选择有用的专家
|
||
- **自由实验** - 如果您想先看到会发生什么，使用 `--preview`
|
||
|
||
**仍然有粗糙边缘：**
|
||
- 复杂编排（spawn、task）可能有点不稳定
|
||
- 某些分析很大程度上取决于您的项目设置
|
||
- 某些命令中的错误处理可以更好
|
||
|
||
**一直在改进：**
|
||
- 我们根据用户反馈积极改进命令
|
||
- 较新的命令（analyze、improve）往往效果更好
|
||
- 自动激活变得越来越智能
|
||
|
||
**不要为记住这个而压力** 🧘♂️
|
||
- SuperClaude 设计为通过使用即可发现
|
||
- 输入 `/` 查看可用命令
|
||
- 当您使用 `--help` 时，命令建议它们能做什么
|
||
- 智能路由处理大部分复杂性
|
||
|
||
**需要帮助？** 查看 GitHub 问题或在卡住时创建一个新问题！🚀
|
||
|
||
---
|
||
|
||
*快乐编码！请记住 - 您可以跳过本指南的大部分内容并通过实践学习。🎯*
|