Two files, one repository
xu-xiang/everything-claude-code-zh ships 2 formats across 3 indexed files. The question worth asking is whether the second one says anything the first does not.
CompareAGENTS.md ↔ CLAUDE.md
| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 1 | 12 | 7 | 5% |
| Commands | 0 | 0 | 5 | 0% |
| Section tags | 2 | 6 | 0 | 25% |
What each file covers
Sections
1 shared · 12 only in A · 7 only in B- − Everything Claude Code (ECC) — 智能体（Agent）指令
- − 可用智能体（Available Agents）
- − 智能体编排（Agent Orchestration）
- − 安全指南（Security Guidelines）
- − 编码风格（Coding Style）
- − 测试要求（Testing Requirements）
- − 开发工作流（Development Workflow）
- − Git 工作流（Git Workflow）
- − 架构模式（Architecture Patterns）
- − 性能优化（Performance）
- − 项目结构（Project Structure）
- − 成功指标（Success Metrics）
- + CLAUDE.md
- + 项目概览 (Project Overview)
- + 运行测试 (Running Tests)
- + 架构设计 (Architecture)
- + 核心命令 (Key Commands)
- + 开发注意事项 (Development Notes)
- + 贡献指南 (Contributing)
- 核心原则
Commands
0 shared · 0 only in A · 5 only in B- + node tests/run-all.js
- + node tests/lib/utils.test.js
- + node tests/lib/package-manager.test.js
- + node tests/hooks/hooks.test.js
- + python-reviewer.md
Section tags
2 shared · 6 only in A · 0 only in B- − test
- − code-style
- − testing-strategy
- − git-pr
- − security
- − performance
- architecture
- agent-behaviour
Line diff
xu-xiang/everything-claude-code-zh · AGENTS.md
@@ −1 @@
1# Everything Claude Code (ECC) — 智能体（Agent）指令
2
3这是一个**生产级 AI 编码插件**，为软件开发提供 13 个专业智能体（Agent）、50+ 个技能（Skill）、33 个命令（Command）以及自动化的钩子（Hook）工作流（Workflow）。
4
5## 核心原则
6
71. **智能体优先（Agent-First）** — 将领域任务委托给专业智能体处理
82. **测试驱动（Test-Driven）** — 先写测试后实现，要求 80% 以上的覆盖率
93. **安全第一（Security-First）** — 绝不在安全性上妥协；验证所有输入
104. **不可变性（Immutability）** — 始终创建新对象，绝不修改现有对象
115. **先规划后执行（Plan Before Execute）** — 在编写代码前先规划复杂功能的实现
12
13## 可用智能体（Available Agents）
14
15| 智能体（Agent） | 用途 | 何时使用 |
16|-------|---------|-------------|
17| planner | 实现规划 | 复杂功能、重构 |
18| architect | 系统设计与可扩展性 | 架构决策 |
19| tdd-guide | 测试驱动开发 | 新功能、错误修复 |
20| code-reviewer | 代码质量与可维护性 | 编写/修改代码后 |
21| security-reviewer | 漏洞检测 | 提交前、敏感代码 |
22| build-error-resolver | 修复构建/类型错误 | 构建失败时 |
23| e2e-runner | 端到端 Playwright 测试 | 关键用户流程 |
24| refactor-cleaner | 死代码清理 | 代码维护 |
25| doc-updater | 文档与代码映射（codemaps） | 更新文档 |
26| go-reviewer | Go 代码审查 | Go 项目 |
27| go-build-resolver | Go 构建错误 | Go 构建失败 |
28| database-reviewer | PostgreSQL/Supabase 专家 | 模式设计、查询优化 |
29| python-reviewer | Python 代码审查 | Python 项目 |
30
31## 智能体编排（Agent Orchestration）
32
33无需用户提示，主动使用智能体：
34- 复杂功能请求 → **planner**
35- 刚刚编写/修改的代码 → **code-reviewer**
36- 错误修复或新功能 → **tdd-guide**
37- 架构决策 → **architect**
38- 安全敏感代码 → **security-reviewer**
39
40对于独立操作使用并行执行 — 同时启动多个智能体。
41
42## 安全指南（Security Guidelines）
43
44**在进行任何提交前：**
45- 无硬编码密钥（API 密钥、密码、令牌）
46- 所有用户输入均已验证
47- 防止 SQL 注入（参数化查询）
48- 防止 XSS（清理 HTML）
49- 已启用 CSRF 保护
50- 身份验证/授权已验证
51- 所有端点均设有频率限制（Rate limiting）
52- 错误消息不会泄露敏感数据
53
54**密钥管理（Secret management）：** 绝不硬编码密钥。使用环境变量或密钥管理器。在启动时验证所需密钥。立即轮换任何暴露的密钥。
55
56**如果发现安全问题：** 停止（STOP） → 使用 security-reviewer 智能体 → 修复关键（CRITICAL）问题 → 轮换暴露的密钥 → 检查代码库是否存在类似问题。
57
58## 编码风格（Coding Style）
59
60**不可变性 (关键)：** 始终创建新对象，绝不直接修改。返回应用更改后的新副本。
61
62**文件组织：** 倾向于多个小文件而非少数大文件。通常为 200-400 行，最多 800 行。按功能/领域组织，而非按类型。高内聚，低耦合。
63
64**错误处理：** 在每个层级处理错误。在 UI 代码中提供用户友好的消息。在服务端记录详细的上下文（Context）。绝不默默吞掉错误。
65
66**输入验证：** 在系统边界验证所有用户输入。使用基于模式（schema-based）的验证。出现错误时快速失败并提供清晰的消息。绝不信任外部数据。
67
68**代码质量自检清单：**
69- 函数简短（<50 行），文件集中（<800 行）
70- 无深度嵌套（>4 层）
71- 正确的错误处理，无硬编码值
72- 易读、命名规范的标识符
73
74## 测试要求（Testing Requirements）
75
76**最低覆盖率：80%**
77
78测试类型（全部必需）：
791. **单元测试（Unit tests）** — 独立函数、实用工具、组件
802. **集成测试（Integration tests）** — API 端点、数据库操作
813. **端到端测试（E2E tests）** — 关键用户流程
82
83**TDD 工作流 (强制)：**
841. 先写测试 (红灯/RED) — 测试应当失败
852. 编写最小化实现 (绿灯/GREEN) — 测试应当通过
863. 重构 (改进/IMPROVE) — 验证覆盖率 80%+
87
88排除故障：检查测试隔离性 → 验证 Mock → 修复实现（除非测试本身错误，否则不要修改测试）。
89
90## 开发工作流（Development Workflow）
91
921. **规划 (Plan)** — 使用 planner 智能体，识别依赖项和风险，分解为多个阶段
932. **TDD** — 使用 tdd-guide 智能体，先写测试，再实现，后重构
943. **审查 (Review)** — 立即使用 code-reviewer 智能体，解决关键（CRITICAL）/高危（HIGH）问题
954. **提交 (Commit)** — 采用约定式提交（Conventional commits）格式，提供详尽的 PR 摘要
96
97## Git 工作流（Git Workflow）
98
99**提交格式：** `<type>: <description>` — 类型：feat, fix, refactor, docs, test, chore, perf, ci
100
101**PR 工作流：** 分析完整提交历史 → 起草详尽摘要 → 包含测试计划 → 使用 `-u` 标志推送。
102
103## 架构模式（Architecture Patterns）
104
105**API 响应格式：** 一致的信封格式，包含成功指示符、数据负载、错误消息和分页元数据。
106
107**仓库模式 (Repository pattern)：** 将数据访问封装在标准接口（findAll, findById, create, update, delete）之后。业务逻辑依赖于抽象接口，而非存储机制。
108
109**骨架项目 (Skeleton projects)：** 搜索经过实战检验的模板，使用并行智能体（安全性、可扩展性、相关性）进行评估，克隆最匹配的模板，并在经过验证的结构中进行迭代。
110
111## 性能优化（Performance）
112
113**上下文管理（Context management）：** 对于大型重构和多文件功能，避免使用上下文窗口最后 20% 的空间。较低敏感度的任务（单个编辑、文档、简单修复）可以容忍更高的利用率。
114
115**构建故障排除：** 使用 build-error-resolver 智能体 → 分析错误 → 逐步修复 → 每次修复后进行验证。
116
117## 项目结构（Project Structure）
118
119```
120agents/ — 13 个专业子智能体
121skills/ — 50+ 个工作流技能和领域知识
122commands/ — 33 个斜杠命令
123hooks/ — 基于触发器的自动化
124rules/ — 始终遵守的准则（通用 + 按语言）
125scripts/ — 跨平台 Node.js 实用工具
126mcp-configs/ — 14 个 MCP 服务器配置
127tests/ — 测试套件
128```
129
130## 成功指标（Success Metrics）
131
132- 所有测试通过且覆盖率达到 80%+
133- 无安全漏洞
134- 代码易读且可维护
135- 性能可接受
136- 满足用户需求
137
xu-xiang/everything-claude-code-zh · CLAUDE.md
@@ +1 @@
1# CLAUDE.md
2
3本文件为 Claude Code (claude.ai/code) 在此仓库中处理代码提供指导。
4
5## 项目概览 (Project Overview)
6
7这是一个 **Claude Code 插件 (Plugin)** —— 一个包含生产级智能体 (Agents)、技能 (Skills)、钩子 (Hooks)、命令 (Commands)、规则 (Rules) 及 MCP 配置 (MCP Configurations) 的集合。本项目为使用 Claude Code 进行软件开发提供了经受过实战检验的工作流 (Workflows)。
8
9## 运行测试 (Running Tests)
10
11```bash
12# 运行所有测试
13node tests/run-all.js
14
15# 运行单个测试文件
16node tests/lib/utils.test.js
17node tests/lib/package-manager.test.js
18node tests/hooks/hooks.test.js
19```
20
21## 架构设计 (Architecture)
22
23项目由以下核心组件组成：
24
25- **agents/** - 用于委派 (Delegation) 的专业子智能体 (Subagents)（如 planner、code-reviewer、tdd-guide 等）
26- **skills/** - 工作流 (Workflow) 定义与领域知识（如编码标准、模式、测试）
27- **commands/** - 用户调用的斜杠命令 (Slash Commands)（如 `/tdd`、`/plan`、`/e2e` 等）
28- **hooks/** - 基于触发器的自动化（如会话持久化、工具使用前/后钩子）
29- **rules/** - 必须始终遵守的准则（如安全性、编码风格、测试要求）
30- **mcp-configs/** - 用于外部集成的 MCP 服务配置
31- **scripts/** - 用于钩子与设置的跨平台 Node.js 工具
32- **tests/** - 针对脚本与工具的测试套件
33
34## 核心命令 (Key Commands)
35
36- `/tdd` - 测试驱动开发 (TDD) 工作流
37- `/plan` - 实现方案规划 (Implementation Planning)
38- `/e2e` - 生成并运行端到端 (E2E) 测试
39- `/code-review` - 质量审查 (Quality Review)
40- `/build-fix` - 修复构建错误
41- `/learn` - 从会话 (Sessions) 中提取模式
42- `/skill-create` - 从 Git 历史记录生成技能
43
44## 开发注意事项 (Development Notes)
45
46- 包管理器 (Package manager) 检测：支持 npm, pnpm, yarn, bun（可通过 `CLAUDE_PACKAGE_MANAGER` 环境变量或项目配置进行设置）
47- 跨平台：通过 Node.js 脚本支持 Windows, macOS, Linux
48- 智能体 (Agent) 格式：带有 YAML Frontmatter (元数据前置块) 的 Markdown 文件（包含名称、描述、工具、模型）
49- 技能 (Skill) 格式：包含明确章节（何时使用、工作原理、示例）的 Markdown 文件
50- 钩子 (Hook) 格式：包含匹配 (Matcher) 条件以及命令/通知钩子的 JSON 文件
51
52## 贡献指南 (Contributing)
53
54请遵循 CONTRIBUTING.md 中的格式要求：
55- 智能体 (Agents)：带有 Frontmatter (name, description, tools, model) 的 Markdown 文件
56- 技能 (Skills)：明确的章节划分（何时使用、工作原理、示例）
57- 命令 (Commands)：带有描述性 Frontmatter 的 Markdown 文件
58- 钩子 (Hooks)：带有匹配器 (Matcher) 和钩子数组的 JSON 文件
59
60文件命名：小写字母加连字符（例如：`python-reviewer.md`, `tdd-workflow.md`）
61
@@ −1 +1 @@
1−# Everything Claude Code (ECC) — 智能体（Agent）指令
1+# CLAUDE.md
22
3−这是一个**生产级 AI 编码插件**，为软件开发提供 13 个专业智能体（Agent）、50+ 个技能（Skill）、33 个命令（Command）以及自动化的钩子（Hook）工作流（Workflow）。
3+本文件为 Claude Code (claude.ai/code) 在此仓库中处理代码提供指导。
44
5−## 核心原则
5+## 项目概览 (Project Overview)
66
7−1. **智能体优先（Agent-First）** — 将领域任务委托给专业智能体处理
8−2. **测试驱动（Test-Driven）** — 先写测试后实现，要求 80% 以上的覆盖率
9−3. **安全第一（Security-First）** — 绝不在安全性上妥协；验证所有输入
10−4. **不可变性（Immutability）** — 始终创建新对象，绝不修改现有对象
11−5. **先规划后执行（Plan Before Execute）** — 在编写代码前先规划复杂功能的实现
7+这是一个 **Claude Code 插件 (Plugin)** —— 一个包含生产级智能体 (Agents)、技能 (Skills)、钩子 (Hooks)、命令 (Commands)、规则 (Rules) 及 MCP 配置 (MCP Configurations) 的集合。本项目为使用 Claude Code 进行软件开发提供了经受过实战检验的工作流 (Workflows)。
128
13−## 可用智能体（Available Agents）
9+## 运行测试 (Running Tests)
1410
15−| 智能体（Agent） | 用途 | 何时使用 |
16−|-------|---------|-------------|
17−| planner | 实现规划 | 复杂功能、重构 |
18−| architect | 系统设计与可扩展性 | 架构决策 |
19−| tdd-guide | 测试驱动开发 | 新功能、错误修复 |
20−| code-reviewer | 代码质量与可维护性 | 编写/修改代码后 |
21−| security-reviewer | 漏洞检测 | 提交前、敏感代码 |
22−| build-error-resolver | 修复构建/类型错误 | 构建失败时 |
23−| e2e-runner | 端到端 Playwright 测试 | 关键用户流程 |
24−| refactor-cleaner | 死代码清理 | 代码维护 |
25−| doc-updater | 文档与代码映射（codemaps） | 更新文档 |
26−| go-reviewer | Go 代码审查 | Go 项目 |
27−| go-build-resolver | Go 构建错误 | Go 构建失败 |
28−| database-reviewer | PostgreSQL/Supabase 专家 | 模式设计、查询优化 |
29−| python-reviewer | Python 代码审查 | Python 项目 |
11+```bash
12+# 运行所有测试
13+node tests/run-all.js
3014
31−## 智能体编排（Agent Orchestration）
15+# 运行单个测试文件
16+node tests/lib/utils.test.js
17+node tests/lib/package-manager.test.js
18+node tests/hooks/hooks.test.js
19+```
3220
33−无需用户提示，主动使用智能体：
34−- 复杂功能请求 → **planner**
35−- 刚刚编写/修改的代码 → **code-reviewer**
36−- 错误修复或新功能 → **tdd-guide**
37−- 架构决策 → **architect**
38−- 安全敏感代码 → **security-reviewer**
21+## 架构设计 (Architecture)
3922
40−对于独立操作使用并行执行 — 同时启动多个智能体。
23+项目由以下核心组件组成：
4124
42−## 安全指南（Security Guidelines）
25+- **agents/** - 用于委派 (Delegation) 的专业子智能体 (Subagents)（如 planner、code-reviewer、tdd-guide 等）
26+- **skills/** - 工作流 (Workflow) 定义与领域知识（如编码标准、模式、测试）
27+- **commands/** - 用户调用的斜杠命令 (Slash Commands)（如 `/tdd`、`/plan`、`/e2e` 等）
28+- **hooks/** - 基于触发器的自动化（如会话持久化、工具使用前/后钩子）
29+- **rules/** - 必须始终遵守的准则（如安全性、编码风格、测试要求）
30+- **mcp-configs/** - 用于外部集成的 MCP 服务配置
31+- **scripts/** - 用于钩子与设置的跨平台 Node.js 工具
32+- **tests/** - 针对脚本与工具的测试套件
4333
44−**在进行任何提交前：**
45−- 无硬编码密钥（API 密钥、密码、令牌）
46−- 所有用户输入均已验证
47−- 防止 SQL 注入（参数化查询）
48−- 防止 XSS（清理 HTML）
49−- 已启用 CSRF 保护
50−- 身份验证/授权已验证
51−- 所有端点均设有频率限制（Rate limiting）
52−- 错误消息不会泄露敏感数据
34+## 核心命令 (Key Commands)
5335
54−**密钥管理（Secret management）：** 绝不硬编码密钥。使用环境变量或密钥管理器。在启动时验证所需密钥。立即轮换任何暴露的密钥。
36+- `/tdd` - 测试驱动开发 (TDD) 工作流
37+- `/plan` - 实现方案规划 (Implementation Planning)
38+- `/e2e` - 生成并运行端到端 (E2E) 测试
39+- `/code-review` - 质量审查 (Quality Review)
40+- `/build-fix` - 修复构建错误
41+- `/learn` - 从会话 (Sessions) 中提取模式
42+- `/skill-create` - 从 Git 历史记录生成技能
5543
56−**如果发现安全问题：** 停止（STOP） → 使用 security-reviewer 智能体 → 修复关键（CRITICAL）问题 → 轮换暴露的密钥 → 检查代码库是否存在类似问题。
44+## 开发注意事项 (Development Notes)
5745
58−## 编码风格（Coding Style）
46+- 包管理器 (Package manager) 检测：支持 npm, pnpm, yarn, bun（可通过 `CLAUDE_PACKAGE_MANAGER` 环境变量或项目配置进行设置）
47+- 跨平台：通过 Node.js 脚本支持 Windows, macOS, Linux
48+- 智能体 (Agent) 格式：带有 YAML Frontmatter (元数据前置块) 的 Markdown 文件（包含名称、描述、工具、模型）
49+- 技能 (Skill) 格式：包含明确章节（何时使用、工作原理、示例）的 Markdown 文件
50+- 钩子 (Hook) 格式：包含匹配 (Matcher) 条件以及命令/通知钩子的 JSON 文件
5951
60−**不可变性 (关键)：** 始终创建新对象，绝不直接修改。返回应用更改后的新副本。
52+## 贡献指南 (Contributing)
6153
62−**文件组织：** 倾向于多个小文件而非少数大文件。通常为 200-400 行，最多 800 行。按功能/领域组织，而非按类型。高内聚，低耦合。
54+请遵循 CONTRIBUTING.md 中的格式要求：
55+- 智能体 (Agents)：带有 Frontmatter (name, description, tools, model) 的 Markdown 文件
56+- 技能 (Skills)：明确的章节划分（何时使用、工作原理、示例）
57+- 命令 (Commands)：带有描述性 Frontmatter 的 Markdown 文件
58+- 钩子 (Hooks)：带有匹配器 (Matcher) 和钩子数组的 JSON 文件
6359
64−**错误处理：** 在每个层级处理错误。在 UI 代码中提供用户友好的消息。在服务端记录详细的上下文（Context）。绝不默默吞掉错误。
65−
66−**输入验证：** 在系统边界验证所有用户输入。使用基于模式（schema-based）的验证。出现错误时快速失败并提供清晰的消息。绝不信任外部数据。
67−
68−**代码质量自检清单：**
69−- 函数简短（<50 行），文件集中（<800 行）
70−- 无深度嵌套（>4 层）
71−- 正确的错误处理，无硬编码值
72−- 易读、命名规范的标识符
73−
74−## 测试要求（Testing Requirements）
75−
76−**最低覆盖率：80%**
77−
78−测试类型（全部必需）：
79−1. **单元测试（Unit tests）** — 独立函数、实用工具、组件
80−2. **集成测试（Integration tests）** — API 端点、数据库操作
81−3. **端到端测试（E2E tests）** — 关键用户流程
82−
83−**TDD 工作流 (强制)：**
84−1. 先写测试 (红灯/RED) — 测试应当失败
85−2. 编写最小化实现 (绿灯/GREEN) — 测试应当通过
86−3. 重构 (改进/IMPROVE) — 验证覆盖率 80%+
87−
88−排除故障：检查测试隔离性 → 验证 Mock → 修复实现（除非测试本身错误，否则不要修改测试）。
89−
90−## 开发工作流（Development Workflow）
91−
92−1. **规划 (Plan)** — 使用 planner 智能体，识别依赖项和风险，分解为多个阶段
93−2. **TDD** — 使用 tdd-guide 智能体，先写测试，再实现，后重构
94−3. **审查 (Review)** — 立即使用 code-reviewer 智能体，解决关键（CRITICAL）/高危（HIGH）问题
95−4. **提交 (Commit)** — 采用约定式提交（Conventional commits）格式，提供详尽的 PR 摘要
96−
97−## Git 工作流（Git Workflow）
98−
99−**提交格式：** `<type>: <description>` — 类型：feat, fix, refactor, docs, test, chore, perf, ci
100−
101−**PR 工作流：** 分析完整提交历史 → 起草详尽摘要 → 包含测试计划 → 使用 `-u` 标志推送。
102−
103−## 架构模式（Architecture Patterns）
104−
105−**API 响应格式：** 一致的信封格式，包含成功指示符、数据负载、错误消息和分页元数据。
106−
107−**仓库模式 (Repository pattern)：** 将数据访问封装在标准接口（findAll, findById, create, update, delete）之后。业务逻辑依赖于抽象接口，而非存储机制。
108−
109−**骨架项目 (Skeleton projects)：** 搜索经过实战检验的模板，使用并行智能体（安全性、可扩展性、相关性）进行评估，克隆最匹配的模板，并在经过验证的结构中进行迭代。
110−
111−## 性能优化（Performance）
112−
113−**上下文管理（Context management）：** 对于大型重构和多文件功能，避免使用上下文窗口最后 20% 的空间。较低敏感度的任务（单个编辑、文档、简单修复）可以容忍更高的利用率。
114−
115−**构建故障排除：** 使用 build-error-resolver 智能体 → 分析错误 → 逐步修复 → 每次修复后进行验证。
116−
117−## 项目结构（Project Structure）
118−
119−```
120−agents/ — 13 个专业子智能体
121−skills/ — 50+ 个工作流技能和领域知识
122−commands/ — 33 个斜杠命令
123−hooks/ — 基于触发器的自动化
124−rules/ — 始终遵守的准则（通用 + 按语言）
125−scripts/ — 跨平台 Node.js 实用工具
126−mcp-configs/ — 14 个 MCP 服务器配置
127−tests/ — 测试套件
128−```
129−
130−## 成功指标（Success Metrics）
131−
132−- 所有测试通过且覆盖率达到 80%+
133−- 无安全漏洞
134−- 代码易读且可维护
135−- 性能可接受
136−- 满足用户需求
60+文件命名：小写字母加连字符（例如：`python-reviewer.md`, `tdd-workflow.md`）
13761
