大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



Everything Claude Code (ECC) 是一个功能强大的 Claude Code 插件集合，提供了大量斜杠命令（slash commands）来增强开发工作流。本文档详细介绍了 ECC 中最常用的 34 个命令，涵盖核心工作流、测试、代码审查、构建修复、会话管理、学习与改进等六大类别。

命令分类说明

• 核心工作流命令：开发过程中最基础、最常用的命令，构成 ECC 的基础工作流。
• 测试相关命令：支持测试驱动开发（TDD）和测试管理的命令。
• 代码审查命令：针对不同编程语言的代码质量检查和安全性审查。
• 构建修复命令：帮助诊断和修复构建错误的命令。
• 会话管理命令：管理 Claude Code 会话的命令，包括保存、恢复、检查点等。
• 学习与改进命令：从会话中提取知识、创建技能、管理本能的命令。

如何查找和使用命令

在 Claude Code 会话中，输入 / 即可查看所有可用命令。命令通常以 / 开头，后跟命令名称，如 /plan。部分命令支持参数和标志，具体用法请参阅各命令的详细说明。

---

1.1 /plan - 实施计划

功能描述： /plan 命令调用 planner 代理，在编写任何代码之前创建全面的实施计划。它会重新陈述需求、评估风险、创建分步实施计划，并等待用户确认后才开始编写代码。

使用时机：

• 开始新功能开发时
• 进行重大的架构变更时
• 处理复杂的重构任务时
• 多个文件/组件将受影响时
• 需求不明确或存在歧义时

基本用法：

/plan [需求描述]

参数说明：

• [需求描述]：简要描述需要实现的功能或任务。如果省略，代理会基于当前对话上下文推断需求。

使用示例： 用户：/plan 我需要添加市场结算时的实时通知功能

代理（planner）输出示例：

实施计划：实时市场结算通知系统

需求重述

• 当用户关注的市场结算时，向用户发送通知
• 支持多种通知渠道（应用内、电子邮件、Webhook）
• 确保通知可靠送达
• 包含市场结果和用户持仓结果

实施阶段

阶段1：数据库架构

• 添加 notifications 表，包含 id、user_id、market_id、type、status、created_at 等字段
• 添加 user_notification_preferences 表用于存储渠道偏好
• 为 user_id 和 market_id 创建索引以提升性能

阶段2：通知服务

• 在 lib/notifications.ts 中创建通知服务
• 使用 BullMQ/Redis 实现通知队列
• 添加失败送达的重试逻辑
• 创建通知模板

阶段3：集成点

• 接入市场结算逻辑（当状态变为 “resolved” 时）
• 查询市场中所有有持仓的用户
• 为每个用户将通知加入队列

阶段4：前端组件

• 在头部创建 NotificationBell 组件
• 添加 NotificationList 模态框
• 通过 Supabase 订阅实现实时更新
• 添加通知偏好设置页面

依赖项

• Redis（用于队列）
• 电子邮件服务（SendGrid/Resend）
• Supabase 实时订阅

风险评估

• 高风险：电子邮件送达率（需要 SPF/DKIM 配置）
• 中风险：每个市场 1000+ 用户时的性能问题
• 中风险：如果市场频繁结算可能导致通知 spam
• 低风险：实时订阅开销

预估复杂度：中

• 后端：4-6 小时
• 前端：3-4 小时
• 测试：2-3 小时
• 总计：9-13 小时

等待确认：是否继续执行此计划？（是/否/修改）

工作流程：

1. 分析需求：重新陈述需求，确保理解正确
2. 分解阶段：将实施分解为具体的、可操作的阶段
3. 识别依赖：确定组件间的依赖关系
4. 评估风险：识别潜在问题和阻碍
5. 预估复杂度：评估实施复杂度（高/中/低）
6. 呈现计划：展示完整计划并等待用户明确确认

注意事项：

• 关键：planner 代理在您明确确认计划（回复“是”、“继续”等肯定回答）之前不会编写任何代码。
• 如果需要修改，可以回复：
  • “修改：[您的修改内容]”
  • “不同方法：[替代方案]”
  • “跳过阶段2，先执行阶段3”
• 计划确认后，可使用 /tdd 进行测试驱动开发，使用 /build-fix 处理构建错误，使用 /code-review 审查完成后的实现。

相关命令：

• /tdd：测试驱动开发，用于实施计划后的代码实现
• /build-fix：如果出现构建错误，用于修复
• /code-review：审查完成后的实现代码
• /prp-plan：更深入的规划，包含 PRD 集成、代码库分析和模式提取

底层技能：

• 技能文件：commands/plan.md
• 代理文件：agents/planner.md

1.2 /tdd - 测试驱动开发

功能描述： /tdd 命令强制执行测试驱动开发（TDD）工作流：首先搭建接口 → 编写失败测试 → 实现功能 → 验证测试覆盖率（80%以上）。这是 ECC 的核心开发工作流之一。

使用时机：

• 实施新功能或模块时
• 修复 bug 并需要确保测试覆盖时
• 重构代码并需要维护测试覆盖率时
• 任何需要高质量、可测试代码的场景

基本用法：

/tdd [功能描述]

参数说明：

• [功能描述]：要实现的 TDD 功能描述。如果省略，将基于当前对话上下文推断。

使用示例： 用户：/tdd 实现一个计算市场流动性分数的函数

代理（TDD 工作流）输出示例：

TDD 工作流：市场流动性分数计算

步骤1：搭建接口（RED） 创建接口文件 lib/liquidity.ts：

export interface MarketData { totalVolume: number bidAskSpread: number activeTraders: number lastTradeTime: Date }

export function calculateLiquidityScore(market: MarketData): number { throw new Error(‘Not implemented’) }

步骤2：编写失败测试（RED） 创建测试文件 lib/liquidity.test.ts：

import { calculateLiquidityScore, MarketData } from ‘./liquidity’

describe(‘calculateLiquidityScore’, () => { test(‘should return high score for liquid market’, () => {

const market: MarketData = { totalVolume: 5000, bidAskSpread: 0.01, activeTraders: 50, lastTradeTime: new Date() } expect(calculateLiquidityScore(market)).toBeGreaterThan(80) 

})

test(‘should return low score for illiquid market’, () => {

const market: MarketData = { totalVolume: 100, bidAskSpread: 0.1, activeTraders: 5, lastTradeTime: new Date(Date.now() - 24 * 60 * 60 * 1000) // 24小时前 } expect(calculateLiquidityScore(market)).toBeLessThan(20) 

})

test(‘should handle edge case: zero volume’, () => {

const market: MarketData = { totalVolume: 0, bidAskSpread: 0.05, activeTraders: 0, lastTradeTime: new Date() } expect(calculateLiquidityScore(market)).toBe(0) 

}) })

运行测试确认失败：

npm test lib/liquidity.test.ts FAIL lib/liquidity.test.ts ✕ should return high score for liquid market ✕ should return low score for illiquid market ✕ should handle edge case: zero volume

步骤3：实现最小化代码（GREEN） 实现 calculateLiquidityScore 函数：

export function calculateLiquidityScore(market: MarketData): number 

运行测试确认通过：

npm test lib/liquidity.test.ts PASS lib/liquidity.test.ts ✓ should return high score for liquid market ✓ should return low score for illiquid market ✓ should handle edge case: zero volume

步骤4：重构（REFACTOR） 优化代码结构，提取常量，提高可读性：

const WEIGHTS = { VOLUME: 0.4, SPREAD: 0.3, TRADERS: 0.2, RECENCY: 0.1, } as const

const SCALE_FACTORS = { VOLUME: 1000, SPREAD: 1000, TRADERS: 10, RECENCY: 10, } as const

export function calculateLiquidityScore(market: MarketData): number

运行测试确认重构后依然通过。

步骤5：验证覆盖率 运行覆盖率测试，确保达到 80%+：

npx jest –coverage lib/liquidity.test.ts

File	% Stmts	% Branch	% Funcs	% Lines	Uncovered Line #s
————	———	———-	———	———	——————-
liquidity.ts	100.00	100.00	100.00	100.00
————	———	———-	———	———	——————-

覆盖率达标：100% 语句覆盖率，100% 分支覆盖率。

工作流程：

1. RED：搭建接口并编写失败测试
2. RED：运行测试确认失败
3. GREEN：实现最小化代码使测试通过
4. REFACTOR：优化代码结构，提高可读性
5. 验证：检查测试覆盖率（必须达到 80%+）

注意事项：

• 严格遵循 RED → GREEN → REFACTOR 循环
• 测试必须先行编写
• 覆盖率必须明确验证，确保达到 80% 以上
• 检查点证据必须清晰保存

相关命令：

• /plan：在 TDD 之前进行规划
• /test-coverage：专门检查测试覆盖率
• /code-review：TDD 完成后进行代码审查
• 语言特定的 TDD 命令：/go-test、/kotlin-test、/rust-test、/cpp-test

底层技能：

• 技能文件：skills/tdd-workflow/SKILL.md
• 命令文件：commands/tdd.md（遗留兼容层）

1.3 /code-review - 代码审查

功能描述： /code-review 命令对本地未提交的更改或 GitHub Pull Request 进行全面的代码质量、安全性和可维护性审查。支持两种模式：本地审查模式（默认）和 PR 审查模式（当提供 PR 编号或 URL 时）。

使用时机：

• 提交代码前进行本地审查
• 审查 GitHub Pull Request
• 确保代码符合安全标准和**实践
• 识别潜在的安全漏洞和代码质量问题

基本用法：

/code-review [pr-number | pr-url | 留空进行本地审查]

参数说明：

• pr-number：GitHub Pull Request 编号（例如：123）
• pr-url：GitHub Pull Request 的完整 URL
• 留空：对本地未提交的更改进行审查

使用示例：

示例1：本地代码审查 /code-review

示例2：审查 GitHub PR #123 /code-review 123

示例3：审查 GitHub PR 通过 URL /code-review https://github.com/owner/repo/pull/456

工作流程：

本地审查模式：

1. 收集阶段：使用 git diff –name-only HEAD 获取更改的文件列表
2. 审查阶段：逐个读取每个更改的文件，检查：
   • 安全问题（关键）：硬编码凭证、API 密钥、SQL 注入漏洞、XSS 漏洞、缺少输入验证、不安全的依赖、路径遍历风险
   • 代码质量（高）：函数超过 50 行、文件超过 800 行、嵌套深度超过 4 层、缺少错误处理、console.log 语句、TODO/FIXME 注释、缺少公共 API 的 JSDoc
   • **实践（中）：突变模式（应使用不可变）、代码/注释中使用表情符号、新代码缺少测试、可访问性问题（a11y）
3. 报告阶段：生成包含以下内容的报告：
   • 严重程度：关键、高、中、低
   • 文件位置和行号
   • 问题描述
   • 建议的修复方案
   • 如果发现关键或高级别问题，则阻止提交

PR 审查模式：

1. 获取阶段：获取 PR 差异、读取完整文件、运行验证
2. 审查阶段：类似于本地审查，但针对 PR 中的所有更改
3. 发布阶段：在 GitHub PR 上发布审查评论

注意事项：

• 如果发现安全问题（关键或高级别），将阻止代码提交
• 永远不批准存在安全漏洞的代码
• 审查过程会检查硬编码的凭证、API 密钥等敏感信息
• 支持 GitHub PR 审查，需要提供 PR 编号或 URL

相关命令：

• 语言特定的代码审查命令：/python-review、/go-review、/kotlin-review、/rust-review、/cpp-review
• /plan：在代码审查前进行规划
• /tdd：在代码审查后验证测试覆盖率
• /verify：完整的验证循环，包含代码审查

底层技能：

• 命令文件：commands/code-review.md
• 基于 PRPs-agentic-eng 的 PR 审查模式，属于 PRP 工作流系列

1.4 /build-fix - 构建修复

功能描述： /build-fix 命令自动检测项目的构建系统，并逐步修复构建和类型错误。它通过最小的、安全的更改来解决问题，一次修复一个错误，确保不会引入新的问题。

使用时机：

• 项目构建失败时（编译错误、类型错误）
• 需要快速修复构建问题以便继续开发时
• 在代码更改后出现构建错误时
• 作为持续集成（CI）失败后的本地修复工具

基本用法：

/build-fix

参数说明： 该命令无需参数，会自动检测项目类型并运行相应的构建命令。

使用示例： 用户：/build-fix

代理（构建修复）输出示例：

构建修复工作流

步骤1：检测构建系统 检测到 package.json 中存在 build 脚本，使用 npm run build 命令。

步骤2：运行构建并收集错误 运行 npm run build，发现 3 个 TypeScript 错误：

错误1：src/utils.ts(15,7): error TS2304: Cannot find name ‘UserData’. 错误2：src/api.ts(42,21): error TS2345: Argument of type ‘string’ is not assignable to parameter of type ‘number’. 错误3：src/components/Button.tsx(8,10): error TS2307: Cannot find module ‘./styles’.

步骤3：逐个修复错误

修复错误1：缺少类型定义 读取 src/utils.ts 第 15 行，发现使用了未定义的 UserData 类型。 修复：添加导入语句 import { UserData } from ‘../types’。

修复错误2：类型不匹配 读取 src/api.ts 第 42 行，发现字符串参数传递给期望数字的函数。 修复：将参数转换为数字 Number(userId)。

修复错误3：缺少模块 读取 src/components/Button.tsx，发现缺少 ./styles 模块。 修复：创建 src/components/styles.ts 文件并导出必要的样式。

步骤4：验证修复 重新运行 npm run build，所有错误已修复，构建成功。

步骤5：总结

• 修复了 3 个构建错误
• 没有引入新的错误
• 构建现在可以通过

工作流程：

1. 检测构建系统：根据项目文件识别构建工具（npm、Cargo、Gradle、Go 等）
2. 解析和分组错误：运行构建命令，捕获错误，按文件路径分组，按依赖顺序排序
3. 修复循环：逐个处理每个错误：
   • 读取文件，查看错误上下文
   • 诊断根本原因（缺少导入、类型错误、语法错误）
   • 使用最小的更改修复错误
   • 重新运行构建验证修复
4. 安全防护：如果出现以下情况，停止并询问用户：
   • 修复引入的错误比解决的问题更多
   • 同一错误尝试 3 次后仍然存在
   • 修复需要架构变更（不仅仅是构建修复）
   • 构建错误源于缺少依赖
5. 总结：显示修复结果、剩余错误、建议的后续步骤

恢复策略：

• 缺少模块/导入：检查包是否安装，建议安装命令
• 类型不匹配：读取两种类型定义，修复较窄的类型
• 循环依赖：识别导入图中的循环，建议提取
• 版本冲突：检查 package.json / Cargo.toml 中的版本约束
• 构建工具配置错误：读取配置文件，与工作的默认配置比较

注意事项：

• 一次只修复一个错误以确保安全
• 优先使用最小的差异，而不是重构
• 如果问题超出构建修复范围，会建议使用其他命令（如 /plan）
• 支持多种构建系统：Node.js/npm、TypeScript、Rust/Cargo、Java/Maven、Gradle、Go、Python 等

相关命令：

• 语言特定的构建修复命令：/go-build、/kotlin-build、/rust-build、/cpp-build、/gradle-build
• /verify：完整的验证循环，包含构建检查
• /plan：如果构建错误需要架构变更，进行规划

底层技能：

• 命令文件：commands/build-fix.md

1.5 /verify - 完整验证循环

功能描述： /verify 命令运行完整的验证循环：构建 → 代码检查 → 测试 → 类型检查。它确保代码在多个维度上都符合质量标准，是发布前的最终验证步骤。

使用时机：

• 代码更改完成后，提交或合并前
• 持续集成（CI）管道中作为质量门
• 发布前进行最终验证
• 需要全面检查代码健康状况时

基本用法：

/verify

参数说明： 该命令无需参数，会根据项目类型自动选择合适的验证深度和顺序。

使用示例： 用户：/verify

代理（验证循环）输出示例：

完整验证循环

步骤1：构建验证 运行 npm run build… ✓ 构建成功，无错误

步骤2：类型检查 运行 npx tsc –noEmit… ✓ 类型检查通过，无类型错误

步骤3：代码检查 运行 npm run lint… ⚠️ 发现 2 个代码风格问题：

• src/utils.ts:15：行长度超过 100 字符
• src/api.ts:42：缺少 JSDoc 注释

步骤4：测试运行 运行 npm test… ✓ 所有测试通过（45 个测试，覆盖率 92%）

步骤5：安全/日志检查 检查安全问题和日志输出… ✓ 未发现硬编码凭证 ✓ 未发现敏感信息泄露 ⚠️ 发现 1 个 console.log 语句：src/debug.ts:8

步骤6：差异审查 审查未提交的更改… ✓ 更改符合项目标准 ⚠️ 建议：为新增的公共函数添加 JSDoc

验证结果

• ✅ 构建：通过
• ✅ 类型：通过
• ⚠️ 代码检查：2 个警告（非阻塞）
• ✅ 测试：通过（覆盖率 92%）
• ⚠️ 安全/日志：1 个警告（非阻塞）
• ⚠️ 差异审查：1 个建议

总体状态：验证通过，有少量建议改进。

工作流程：

1. 构建验证：运行项目构建命令，确保编译/构建成功
2. 类型检查：运行类型检查器（如 TypeScript、MyPy 等），确保类型安全
3. 代码检查：运行代码检查工具（如 ESLint、Pylint 等），确保代码风格一致
4. 测试运行：运行测试套件，确保功能正确且测试覆盖率达标
5. 安全/日志检查：检查安全漏洞（硬编码凭证、敏感信息）和调试日志
6. 差异审查：审查未提交的更改，确保符合项目标准
7. 报告结果：提供每个步骤的验证结果和总体状态

注意事项：

• 验证深度会根据用户请求的模式和项目类型自动调整
• 验证顺序会根据当前仓库的配置进行优化
• 报告仅包含验证结论和阻碍因素，而不是完整的检查清单
• 如果任何关键步骤失败（构建、类型检查、测试失败），验证将标记为失败
• 警告和建议不会阻塞验证通过，但会提供改进建议

相关命令：

• /build-fix：专门修复构建错误
• /test-coverage：专门检查测试覆盖率
• /code-review：专门的代码审查
• /quality-gate：质量门检查，专注于项目标准

底层技能：

• 技能文件：skills/verification-loop/SKILL.md
• 命令文件：commands/verify.md（遗留兼容层）

1.6 /quality-gate - 质量门检查

功能描述： /quality-gate 命令按需对文件或项目范围运行 ECC 质量管道。它检测语言/工具，运行格式化检查、代码检查/类型检查，并生成简洁的修复清单。这是钩子（hook）行为的手动调用版本。

使用时机：

• 在提交前手动运行质量检查
• 检查特定文件或目录的质量状况
• 作为 CI/CD 管道的一部分进行质量验证
• 需要自动修复代码格式问题时

基本用法：

/quality-gate [路径|.] [–fix] [–strict]

参数说明：

• [路径|.]：可选的目标路径，默认为当前目录（.）
• –fix：可选，允许自动格式化/修复（在配置支持的情况下）
• –strict：可选，在支持的情况下将警告视为失败

使用示例：

示例1：检查当前目录 /quality-gate

示例2：检查特定目录 /quality-gate src/components

示例3：检查并自动修复 /quality-gate src/utils –fix

示例4：严格模式检查 /quality-gate . –strict

工作流程：

1. 检测语言/工具：根据目标路径检测项目语言和工具链
2. 运行格式化检查：运行格式化工具（如 Prettier、Black、gofmt 等）
3. 运行代码检查/类型检查：运行代码检查（ESLint、Pylint 等）和类型检查（TypeScript、MyPy 等）
4. 生成修复清单：提供简洁的问题列表和修复建议

输出示例： 用户：/quality-gate src/utils –fix

代理（质量门）输出示例：

质量门检查：src/utils

检测到的工具

• 语言：TypeScript
• 格式化工具：Prettier
• 代码检查工具：ESLint
• 类型检查工具：TypeScript

检查结果

格式化检查 ⚠️ 发现 3 个格式化问题：

• src/utils/date.ts:15：行尾缺少分号
• src/utils/string.ts:42：缩进不一致（应为 2 个空格，实际为 4 个）
• src/utils/math.ts:8：超过最大行长度（120 > 100）

✅ 自动修复已应用（使用 –fix 标志）

代码检查 ⚠️ 发现 2 个代码检查问题：

• src/utils/date.ts:30：使用 any 类型，应使用具体类型
• src/utils/string.ts:55：未使用的变量 temp

类型检查 ✅ 类型检查通过，无错误

修复清单

1. 修复 src/utils/date.ts:30：将 any 替换为具体类型
2. 修复 src/utils/string.ts:55：删除未使用的变量 temp 或使用它

总体状态

• 格式化：已自动修复
• 代码检查：2 个警告（需要手动修复）
• 类型检查：通过

注意事项：

• 此命令是钩子行为的手动调用版本，提供相同的检查但由操作员触发
• 使用 –fix 标志可以自动修复格式化问题，但代码逻辑问题仍需手动修复
• 使用 –strict 标志会将警告视为失败，适用于 CI/CD 环境
• 支持多种语言和工具链：JavaScript/TypeScript、Python、Go、Rust、Java/Kotlin 等
• 检查范围可以是单个文件、目录或整个项目

相关命令：

• /verify：完整的验证循环，包含质量门检查
• /code-review：更全面的代码审查，包含安全性和**实践
• /build-fix：专门修复构建错误

底层技能：

• 命令文件：commands/quality-gate.md

---

2.1 /e2e - 端到端测试

功能描述： /e2e 命令生成并运行 Playwright 端到端测试，捕获屏幕截图、视频和跟踪信息。它模拟真实用户操作，验证整个应用流程。

使用时机：

• 需要验证关键用户流程时
• 发布前进行端到端测试
• 回归测试确保功能完整
• 跨浏览器兼容性测试

基本用法：

/e2e [测试描述]

示例：

/e2e 测试用户登录流程

生成登录测试脚本，模拟用户输入凭据、点击登录按钮、验证重定向。

相关命令：/tdd、/test-coverage

2.2 /test-coverage - 测试覆盖率

功能描述： /test-coverage 命令报告测试覆盖率，识别测试覆盖的空白区域。它分析测试套件，显示语句、分支、函数和行的覆盖率。

使用时机：

• 评估测试套件的完整性
• 识别需要更多测试的代码区域
• 确保满足覆盖率要求（如80%+）
• 代码更改后验证测试覆盖率

基本用法：

/test-coverage [目标路径]

示例：

/test-coverage src/components

分析 src/components 目录下的测试覆盖率，生成覆盖率报告并指出未覆盖的代码行。

相关命令：/tdd、/verify

2.3 /go-test - Go语言TDD

功能描述： /go-test 命令为 Go 语言提供测试驱动开发（TDD）工作流，支持表驱动测试，确保 80%+ 的测试覆盖率（使用 go test -cover）。

使用时机：

• 开发 Go 语言功能时
• 需要遵循 Go **实践的 TDD 时
• 确保 Go 代码具有高质量的测试覆盖率时

基本用法：

/go-test [功能描述]

示例：

/go-test 实现一个 HTTP 中间件

创建 Go 测试文件，使用表驱动测试覆盖各种场景，然后实现中间件功能。

相关命令：/tdd、/go-review、/go-build

2.4 /kotlin-test - Kotlin语言TDD

功能描述： /kotlin-test 命令为 Kotlin 语言提供测试驱动开发（TDD）工作流，使用 Kotest 测试框架和 Kover 覆盖率工具。

使用时机：

• 开发 Kotlin/JVM 或 Kotlin Multiplatform 功能时
• 需要遵循 Kotlin **实践的 TDD 时
• 确保 Kotlin 代码具有高质量的测试覆盖率时

基本用法：

/kotlin-test [功能描述]

示例：

/kotlin-test 实现一个数据类验证器

创建 Kotlin 测试文件，使用 Kotest 的丰富断言，然后实现验证器逻辑。

相关命令：/tdd、/kotlin-review、/kotlin-build

2.5 /rust-test - Rust语言TDD

功能描述： /rust-test 命令为 Rust 语言提供测试驱动开发（TDD）工作流，支持单元测试和集成测试（使用 cargo test）。

使用时机：

• 开发 Rust 库或应用程序时
• 需要遵循 Rust **实践的 TDD 时
• 确保 Rust 代码具有全面测试时

基本用法：

/rust-test [功能描述]

示例：

/rust-test 实现一个解析器组合子

创建 Rust 测试模块，编写单元测试和集成测试，然后实现解析器功能。

相关命令：/tdd、/rust-review、/rust-build

2.6 /cpp-test - C++语言TDD

功能描述： /cpp-test 命令为 C++ 语言提供测试驱动开发（TDD）工作流，使用 GoogleTest 测试框架和 gcov/lcov 覆盖率工具。

使用时机：

• 开发 C++ 库或应用程序时
• 需要遵循现代 C++ **实践的 TDD 时
• 确保 C++ 代码具有高质量的测试覆盖率时

基本用法：

/cpp-test [功能描述]

示例：

/cpp-test 实现一个矩阵运算库

创建 GoogleTest 测试用例，编写测试覆盖各种矩阵操作，然后实现矩阵运算功能。

相关命令：/tdd、/cpp-review、/cpp-build

---

3.1 /python-review - Python代码审查

功能描述： /python-review 命令对 Python 代码进行全面的代码审查，检查 PEP 8 规范、类型提示、安全问题和惯用模式。

使用时机：

• 审查 Python 代码质量时
• 确保代码符合 Python **实践时
• 识别 Python 特定安全漏洞时

基本用法：

/python-review [文件或目录]

示例：

/python-review src/api.py

审查 src/api.py 文件，检查 PEP 8 合规性、类型提示、安全性等。

相关命令：/code-review、/verify

3.2 /go-review - Go代码审查

功能描述： /go-review 命令对 Go 代码进行全面的代码审查，检查惯用模式、并发安全性、错误处理和 Go **实践。

使用时机：

• 审查 Go 代码质量时
• 确保代码符合 Go 惯用模式时
• 识别并发安全问题和错误处理缺陷时

基本用法：

/go-review [文件或目录]

示例：

/go-review cmd/server

审查 cmd/server 目录下的 Go 代码，检查惯用模式、错误处理、并发安全等。

相关命令：/code-review、/go-test、/go-build

3.3 /kotlin-review - Kotlin代码审查

功能描述： /kotlin-review 命令对 Kotlin 代码进行全面的代码审查，检查空安全、协程安全性、清洁架构和 Kotlin **实践。

使用时机：

• 审查 Kotlin 代码质量时
• 确保代码充分利用 Kotlin 特性时
• 识别空安全问题和协程安全缺陷时

基本用法：

/kotlin-review [文件或目录]

示例：

/kotlin-review src/main/kotlin

审查 Kotlin 代码，检查空安全、协程使用、扩展函数等**实践。

相关命令：/code-review、/kotlin-test、/kotlin-build

3.4 /rust-review - Rust代码审查

功能描述： /rust-review 命令对 Rust 代码进行全面的代码审查，检查所有权、生命周期、不安全使用和 Rust **实践。

使用时机：

• 审查 Rust 代码质量时
• 确保代码符合 Rust 所有权模型时
• 识别不安全代码和生命周期问题时

基本用法：

/rust-review [文件或目录]

示例：

/rust-review src/lib.rs

审查 Rust 代码，检查所有权、生命周期、错误处理、unsafe 使用等。

相关命令：/code-review、/rust-test、/rust-build

3.5 /cpp-review - C++代码审查

功能描述： /cpp-review 命令对 C++ 代码进行全面的代码审查，检查内存安全、现代惯用法、并发安全和 C++ **实践。

使用时机：

• 审查 C++ 代码质量时
• 确保代码使用现代 C++ 特性时
• 识别内存安全问题和并发缺陷时

基本用法：

/cpp-review [文件或目录]

示例：

/cpp-review include/ library.cpp

审查 C++ 代码，检查内存管理、智能指针使用、移动语义、并发安全等。

相关命令：/code-review、/cpp-test、/cpp-build

---

4.1 /go-build - Go构建修复

功能描述： /go-build 命令专门修复 Go 项目的构建错误，处理导入问题、类型错误和 Go 特定的构建问题。

使用时机：

• Go 项目构建失败时
• 需要修复 Go 编译错误时
• Go 依赖管理出现问题时

基本用法：

/go-build

示例：

/go-build

检测 Go 项目，运行 go build ./…，逐个修复编译错误。

相关命令：/build-fix、/go-test、/go-review

4.2 /kotlin-build - Kotlin构建修复

功能描述： /kotlin-build 命令专门修复 Kotlin 项目的构建错误，处理 Gradle/Maven 配置、类型推断问题和 Kotlin 特定的编译问题。

使用时机：

• Kotlin 项目构建失败时
• 需要修复 Kotlin 编译错误时
• Gradle/Maven 依赖冲突时

基本用法：

/kotlin-build

示例：

/kotlin-build

检测 Kotlin 项目，运行 Gradle 或 Maven 构建，逐个修复编译错误。

相关命令：/build-fix、/kotlin-test、/kotlin-review

4.3 /rust-build - Rust构建修复

功能描述： /rust-build 命令专门修复 Rust 项目的构建错误，处理 Cargo 依赖、所有权问题和 Rust 特定的编译错误。

使用时机：

• Rust 项目构建失败时
• 需要修复 Cargo 编译错误时
• 依赖版本冲突或特性问题时

基本用法：

/rust-build

示例：

/rust-build

检测 Rust 项目，运行 cargo build，逐个修复编译错误。

相关命令：/build-fix、/rust-test、/rust-review

4.4 /cpp-build - C++构建修复

功能描述： /cpp-build 命令专门修复 C++ 项目的构建错误，处理 CMake/Makefile 配置、头文件依赖和 C++ 特定的编译问题。

使用时机：

• C++ 项目构建失败时
• 需要修复 C++ 编译错误时
• 链接错误或头文件问题时

基本用法：

/cpp-build

示例：

/cpp-build

检测 C++ 项目，运行 CMake 或 Makefile 构建，逐个修复编译错误。

相关命令：/build-fix、/cpp-test、/cpp-review

4.5 /gradle-build - Gradle构建修复

功能描述： /gradle-build 命令专门修复 Gradle 项目的构建错误，处理 Gradle 配置、依赖冲突和 Java/Kotlin 编译问题。

使用时机：

• Gradle 项目构建失败时
• 需要修复 Gradle 编译错误时
• 依赖解析失败或插件冲突时

基本用法：

/gradle-build

示例：

/gradle-build

检测 Gradle 项目，运行 ./gradlew build，逐个修复构建错误。

相关命令：/build-fix、/kotlin-build、/java-build（如存在）

---

5.1 /save-session - 保存会话

功能描述： /save-session 命令保存当前 Claude Code 会话状态，包括对话历史、上下文和当前任务状态，以便后续恢复。

使用时机：

• 长时间会话需要中断时
• 重要进展需要保存时
• 会话即将超时或需要暂停时

基本用法：

/save-session [会话名称]

示例：

/save-session 用户认证功能开发

保存当前会话，生成会话 ID 和恢复信息。

相关命令：/resume-session、/sessions

5.2 /resume-session - 恢复会话

功能描述： /resume-session 命令加载最近保存的会话状态，恢复之前的对话历史、上下文和任务进度。

使用时机：

• 继续之前中断的会话时
• 需要恢复之前的工作状态时
• 切换回重要任务时

基本用法：

/resume-session [会话ID或名称]

示例：

/resume-session 用户认证功能开发

加载之前保存的会话，恢复所有上下文和状态。

相关命令：/save-session、/sessions

5.3 /sessions - 会话管理

功能描述： /sessions 命令浏览、搜索和管理保存的会话历史，支持查看、筛选和删除会话。

使用时机：

• 查看所有保存的会话时
• 搜索特定会话时
• 管理会话存储空间时

基本用法：

/sessions [搜索词]

示例：

/sessions 认证

列出所有包含“认证”关键词的保存会话。

相关命令：/save-session、/resume-session

5.4 /checkpoint - 检查点标记

功能描述： /checkpoint 命令标记当前会话的检查点，记录重要进展状态，便于后续回溯或比较。

使用时机：

• 完成重要里程碑时
• 需要标记可回溯状态时
• 复杂任务需要多个检查点时

基本用法：

/checkpoint [检查点描述]

示例：

/checkpoint 完成用户模型设计

标记当前会话状态，记录检查点描述和时间戳。

相关命令：/save-session、/sessions

5.5 /aside - 旁路问答

功能描述： /aside 命令回答快速侧问题而不丢失当前任务上下文，适用于临时查询或澄清问题。

使用时机：

• 需要快速查询信息时
• 澄清与当前任务相关的问题时
• 不想中断主要任务流程时

基本用法：

/aside [问题]

示例：

/aside React 中如何条件渲染组件？

快速回答 React 条件渲染问题，然后恢复主任务上下文。

相关命令：无特定相关命令，用于辅助主任务。

5.6 /context-budget - 上下文预算分析

功能描述： /context-budget 命令分析当前上下文窗口使用情况，帮助优化对话长度和内容管理。

使用时机：

• 对话接近上下文限制时
• 需要优化上下文使用效率时
• 管理长对话的存储空间时

基本用法：

/context-budget

示例：

/context-budget

分析当前上下文使用情况，显示已用/剩余token数量，提供优化建议。

相关命令：/save-session、/resume-session

---

6.1 /learn - 模式提取

功能描述： /learn 命令从当前会话中提取可重用的模式和知识，转化为可保存的本能（instinct）或技能。

使用时机：

• 完成有价值的任务或解决问题后
• 发现可重用的工作模式时
• 需要将经验转化为持久知识时

基本用法：

/learn [模式名称]

示例：

/learn API错误处理模式

分析当前会话，提取API错误处理的**实践和模式，保存为可重用知识。

相关命令：/learn-eval、/evolve、/promote

6.2 /learn-eval - 学习评估

功能描述： /learn-eval 命令从会话中提取模式并在保存前进行自我评估质量，确保提取的知识具有高质量和实用性。

使用时机：

• 提取重要知识并需要质量保证时
• 确保学习内容符合标准时
• 创建正式的可重用技能前

基本用法：

/learn-eval [模式名称]

示例：

/learn-eval 数据库迁移**实践

提取数据库迁移模式，评估其完整性、准确性和实用性，然后保存。

相关命令：/learn、/evolve、/skill-create

6.3 /evolve - 本能进化

功能描述： /evolve 命令分析学习到的本能，建议进化的技能结构，优化知识组织和重用效率。

使用时机：

• 本能库积累到一定规模时
• 需要优化知识组织结构时
• 提高本能重用效率时

基本用法：

/evolve

示例：

/evolve

分析现有的本能库，识别模式、冗余和优化机会，建议改进的技能结构。

相关命令：/learn、/learn-eval、/instinct-status

6.4 /promote - 本能提升

功能描述： /promote 命令将项目范围的本能提升到全局范围，使有价值的模式在所有项目中可用。

使用时机：

• 发现具有跨项目价值的本能时
• 需要共享**实践时
• 标准化工作流程时

基本用法：

/promote [本能名称]

示例：

/promote React组件测试模式

将当前项目的React组件测试模式提升为全局本能，使其在所有项目中可用。

相关命令：/learn、/learn-eval、/instinct-status

6.5 /instinct-status - 本能状态

功能描述： /instinct-status 命令检查本能的状态和健康状况，显示可用本能、使用统计和存储信息。

使用时机：

• 查看本能库状态时
• 诊断本能相关问题时
• 管理本能存储空间时

基本用法：

/instinct-status

示例：

/instinct-status

显示本能库统计信息：本能数量、存储使用、最近使用情况等。

相关命令：/learn、/evolve、/promote

6.6 /skill-create - 技能创建

功能描述： /skill-create 命令分析本地git历史，提取模式并生成可重用的技能，将开发经验转化为自动化工具。

使用时机：

• 从成功的开发任务中创建技能时
• 自动化重复性工作流程时
• 将专家知识转化为可重用工具时

基本用法：

/skill-create [技能描述]

示例：

/skill-create 数据库迁移技能

分析git历史中的数据库迁移相关提交，提取**实践，创建数据库迁移技能。

相关命令：/learn、/learn-eval、/evolve

---

7.1 开始新功能开发

工作流程：

1. 研究与重用：在编写新代码前，先搜索现有实现
   • 使用 GitHub 代码搜索（gh search repos、gh search code）
   • 查阅库文档确认 API 行为
   • 搜索包注册表（npm、PyPI、crates.io 等）
   • 优先采用或移植经验证的方法
2. 规划阶段：使用 /plan 命令

   /plan 实现用户认证功能

   • 创建详细实现计划
   • 识别依赖和风险
   • 分解为可执行的阶段
3. 测试驱动开发：使用 /tdd 命令

   /tdd 实现登录验证逻辑

   • 先写失败测试（RED）
   • 实现代码通过测试（GREEN）
   • 重构优化（IMPROVE）
   • 确保 80%+ 测试覆盖率
4. 代码审查：使用 /code-review 命令

   /code-review

   • 检查代码质量和安全性
   • 解决关键和高优先级问题
5. 验证：使用 /verify 命令

   /verify

   • 运行完整验证循环
   • 确保构建、类型、测试全部通过

核心命令组合： /plan → /tdd → /code-review → /verify

7.2 修复Bug流程

工作流程：

1. 重现问题：确认 bug 可重现，收集相关错误信息
2. 定位问题：分析错误日志，确定问题根源
3. 修复构建错误：如果存在构建问题，使用 /build-fix

   /build-fix

4. 编写测试：创建重现 bug 的测试用例

   /tdd 修复用户数据导出失败的bug

5. 实施修复：最小化更改解决问题
6. 验证修复：运行相关测试，确保修复有效
7. 全面验证：使用 /verify 确保修复不引入新问题

   /verify

8. 代码审查：使用 /code-review 审查修复

   /code-review

核心命令组合： /build-fix（如需要）→ /tdd → /verify → /code-review

7.3 代码审查流程

工作流程：

1. 本地审查：提交前进行本地审查

   /code-review

   • 检查安全问题（硬编码凭证、SQL注入等）
   • 检查代码质量（函数长度、嵌套深度等）
   • 检查**实践（错误处理、测试覆盖等）
2. 语言特定审查：针对特定语言使用专业审查

   /python-review src/api.py

   /go-review cmd/server

   /rust-review src/lib.rs

3. 质量门检查：运行质量管道

   /quality-gate src –fix

   • 自动修复格式化问题
   • 检查代码风格一致性
4. 测试覆盖率验证：确保测试充分

   /test-coverage src

5. 端到端测试：验证关键用户流程

   /e2e 测试用户注册流程

核心命令组合： /code-review → 语言特定审查 → /quality-gate → /test-coverage

7.4 会话管理**实践

工作流程：

1. 定期保存：重要进展后保存会话

   /save-session 完成用户模型设计

2. 检查点标记：关键里程碑标记检查点

   /checkpoint 实现核心业务逻辑

3. 上下文管理：监控上下文使用情况

   /context-budget

   • 优化对话长度
   • 管理存储空间
4. 会话恢复：中断后恢复工作

   /resume-session 完成用户模型设计

5. 会话管理：查看和管理所有会话

   /sessions 用户认证

6. 旁路问答：快速查询不中断主任务

   /aside React中useEffect的依赖数组如何工作？

**实践：

• 每个功能模块完成后保存会话
• 复杂任务设置多个检查点
• 定期清理不必要的会话
• 使用旁路问答保持主任务专注

7.5 持续学习工作流

工作流程：

1. 模式提取：从成功任务中提取知识

   /learn API错误处理模式

2. 学习评估：评估提取模式的质量

   /learn-eval 数据库迁移**实践

3. 技能创建：从git历史创建可重用技能

   /skill-create 数据库迁移技能

4. 本能管理：查看和管理学习成果

   /instinct-status

5. 本能进化：优化知识组织结构

   /evolve

6. 本能提升：将有价值模式提升为全局可用

   /promote React组件测试模式

持续改进循环： /learn → /learn-eval → /skill-create → /evolve → /promote

价值：

• 将个人经验转化为团队资产
• 标准化**实践
• 减少重复工作
• 加速新成员上手

---

8.1 按功能分类的命令速查表

8.2 按使用频率排序的命令列表

说明：以下排序基于日常开发中的典型使用频率，可作为“先学什么、常用什么”的优先级参考。

建议的学习顺序：

1. 先掌握 4 个通用核心命令：/plan、/tdd、/verify、/code-review
2. 再补上 4 个高频辅助命令：/build-fix、/test-coverage、/save-session、/resume-session
3. 最后根据技术栈学习语言专用测试、审查和构建命令

最常用的黄金组合：

• 新功能开发：/plan → /tdd → /code-review → /verify
• Bug 修复：/build-fix → /tdd → /verify
• 发布前检查：/test-coverage → /e2e → /quality-gate
• 知识沉淀：/learn → /learn-eval → /skill-create

8.3 命令参数速查

参数使用建议：

• 任务型命令尽量补上清晰描述，例如 /plan、/tdd、/e2e、/learn
• 文件型命令优先传入具体目录或文件，缩小分析范围，例如 /python-review src/api.py
• 会话型命令建议使用易搜索的中文名称，便于后续 /sessions 和 /resume-session
• 无参数命令通常依赖当前工作目录与当前对话上下文，因此在执行前最好先明确主任务

---

命令安装与配置

ECC 的安装通常分为两部分：插件安装，以及规则（rules）安装。只安装插件可以使用一部分能力，但如果希望获得更完整、更稳定的行为约束，建议同时安装规则。

推荐安装路径：

1. 先添加 ECC 市场并安装插件
2. 再克隆仓库并执行安装脚本安装规则
3. 最后在 Claude Code 中验证命令是否可见

插件安装示例：

/plugin marketplace add affaan-m/everything-claude-code

/plugin install ecc@ecc

规则安装示例（macOS/Linux）：

git clone https://github.com/affaan-m/everything-claude-code.git

cd everything-claude-code

npm install

./install.sh –profile full

规则安装示例（Windows PowerShell）：

git clone https://github.com/affaan-m/everything-claude-code.git

cd everything-claude-code

npm install

.install.ps1 –profile full

按语言安装示例：

./install.sh typescript

./install.sh python

./install.sh golang

./install.sh swift

关键配置点：

• Node.js 版本要求为 >=18
• 支持的包管理器包括 npm、pnpm、yarn、bun
• 可以通过环境变量 CLAUDE_PACKAGE_MANAGER 指定首选包管理器
• multi- 命令还需要额外安装 ccg-workflow 运行时

手动安装规则时的注意事项：

• 始终复制整个规则目录，例如 rules/common、rules/typescript
• 不要把多个规则目录拍平复制到同一层，否则会覆盖同名文件
• 语言规则依赖 common 规则中的相对路径引用，因此 common 层通常需要一起安装

安装后的简单验证：

1. 在 Claude Code 会话中输入 /
2. 确认能看到 /plan、/tdd、/verify 等命令
3. 运行一个简单命令，例如 /plan 添加一个登录表单
4. 如需检查命令总览，可参考仓库中的 COMMANDS-QUICK-REF.md

常见问题解答

Q1：为什么安装后看不到某些命令？ A：最常见原因是只安装了插件但没有安装规则，或者当前宿主工具没有成功加载插件目录。先确认插件已安装，再确认规则已按说明安装完成。

Q2：为什么 multi- 命令不能使用？ A：这些命令不只依赖基础插件，还依赖额外的 ccg-workflow 运行时。如果没有执行对应初始化安装，这些命令通常不会正常工作。

Q3：为什么手动复制规则后行为异常？ A：很可能是把 rules/common 和语言规则目录内的文件“拍平”复制了。ECC 的规则目录依赖分层结构和相对路径引用，必须复制整个目录，而不是只复制其中的单个文件。

Q4：命令前面为什么有时要写成 /ecc:plan，有时是 /plan？ A：如果你是通过插件市场安装，常见形式是命名空间写法，例如 /ecc:plan；如果是手动安装旧式命令兼容层，通常可以直接使用 /plan。

Q5：如何选择先学哪些命令？ A：建议先掌握 /plan、/tdd、/code-review、/verify 这 4 个核心命令，再根据语言和项目类型学习语言专用命令。

Q6：/verify 和 /quality-gate 有什么区别？ A：/verify 偏向完整验证循环，覆盖构建、类型、测试、安全等多个维度；/quality-gate 更偏向按路径或项目范围执行质量检查，并支持 –fix、–strict 这类参数。

Q7：如何确认当前 ECC 版本？ A：可以查看仓库根目录的 VERSION 文件，或查看 package.json 中的 version 字段。本文档基于的版本是 1.10.0。

Q8：如果命令行为和文档不完全一致怎么办？ A：优先以当前仓库中的命令实现、技能文件和 README 为准。ECC 迭代较快，文档可能滞后于个别命令实现细节。

相关资源链接

• GitHub 仓库主页：https://github.com/affaan-m/everything-claude-code
• 英文 README：https://github.com/affaan-m/everything-claude-code/blob/main/README.md
• 中文 README：https://github.com/affaan-m/everything-claude-code/blob/main/README.zh-CN.md
• 命令速查表：COMMANDS-QUICK-REF.md
• 安装与规则说明：rules/README.md
• 长篇指南：the-longform-guide.md
• 精简指南：the-shortform-guide.md
• 安全指南：the-security-guide.md
• 故障排查：TROUBLESHOOTING.md
• 贡献指南：CONTRIBUTING.md
• 更新日志：CHANGELOG.md
• 问题反馈：https://github.com/affaan-m/everything-claude-code/issues

---

本文档基于 ECC 版本：1.10.0

最后更新：2026年4月10日

内容由AI整理生成