| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 1 | 14 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 1 | 0 | 7 | 13% |
What each file covers
Sections
0 shared · 1 only in A · 14 only in B- − 与其他规则的集成
- + Everything Claude Code (ECC) — Agent Instructions
- + Core Principles
- + Available Agents
- + Agent Orchestration
- + Security Guidelines
- + Coding Style
- + Testing Requirements
- + Development Workflow
- + Workflow Surface Policy
- + Git Workflow
- + Architecture Patterns
- + Performance
- + Project Structure
- + Success Metrics
Commands
neither file has anySection tags
1 shared · 0 only in A · 7 only in B- + build
- + test
- + code-style
- + architecture
- + security
- + performance
- + agent-behaviour
- git-pr
Line diff
ThanhTrunggDEV/DontBeLazy · .cursor/rules/zh-code-review.mdc
@@ −1 @@
1# 代码审查标准
2
3## 目的
4
5代码审查确保代码合并前的质量、安全性和可维护性。此规则定义何时以及如何进行代码审查。
6
7## 何时审查
8
9**强制审查触发条件：**
10
11- 编写或修改代码后
12- 提交到共享分支之前
13- 更改安全敏感代码时（认证、支付、用户数据）
14- 进行架构更改时
15- 合并 pull request 之前
16
17**审查前要求：**
18
19在请求审查之前，确保：
20
21- 所有自动化检查（CI/CD）已通过
22- 合并冲突已解决
23- 分支已与目标分支同步
24
25## 审查检查清单
26
27在标记代码完成之前：
28
29- [ ] 代码可读且命名良好
30- [ ] 函数聚焦（<50 行）
31- [ ] 文件内聚（<800 行）
32- [ ] 无深层嵌套（>4 层）
33- [ ] 错误显式处理
34- [ ] 无硬编码密钥或凭据
35- [ ] 无 console.log 或调试语句
36- [ ] 新功能有测试
37- [ ] 测试覆盖率满足 80% 最低要求
38
39## 安全审查触发条件
40
41**停止并使用 security-reviewer 代理当：**
42
43- 认证或授权代码
44- 用户输入处理
45- 数据库查询
46- 文件系统操作
47- 外部 API 调用
48- 加密操作
49- 支付或金融代码
50
51## 审查严重级别
52
53| 级别 | 含义 | 行动 |
54|-------|---------|--------|
55| CRITICAL（关键） | 安全漏洞或数据丢失风险 | **阻止** - 合并前必须修复 |
56| HIGH（高） | Bug 或重大质量问题 | **警告** - 合并前应修复 |
57| MEDIUM（中） | 可维护性问题 | **信息** - 考虑修复 |
58| LOW（低） | 风格或次要建议 | **注意** - 可选 |
59
60## 代理使用
61
62使用这些代理进行代码审查：
63
64| 代理 | 用途 |
65|-------|--------|
66| **code-reviewer** | 通用代码质量、模式、最佳实践 |
67| **security-reviewer** | 安全漏洞、OWASP Top 10 |
68| **typescript-reviewer** | TypeScript/JavaScript 特定问题 |
69| **python-reviewer** | Python 特定问题 |
70| **go-reviewer** | Go 特定问题 |
71| **rust-reviewer** | Rust 特定问题 |
72
73## 审查工作流
74
75```
761. 运行 git diff 了解更改
772. 先检查安全检查清单
783. 审查代码质量检查清单
794. 运行相关测试
805. 验证覆盖率 >= 80%
816. 使用适当的代理进行详细审查
82```
83
84## 常见问题捕获
85
86### 安全
87
88- 硬编码凭据（API 密钥、密码、令牌）
89- SQL 注入（查询中的字符串拼接）
90- XSS 漏洞（未转义的用户输入）
91- 路径遍历（未净化的文件路径）
92- CSRF 保护缺失
93- 认证绕过
94
95### 代码质量
96
97- 大函数（>50 行）- 拆分为更小的
98- 大文件（>800 行）- 提取模块
99- 深层嵌套（>4 层）- 使用提前返回
100- 缺少错误处理 - 显式处理
101- 变更模式 - 优先使用不可变操作
102- 缺少测试 - 添加测试覆盖
103
104### 性能
105
106- N+1 查询 - 使用 JOIN 或批处理
107- 缺少分页 - 给查询添加 LIMIT
108- 无界查询 - 添加约束
109- 缺少缓存 - 缓存昂贵操作
110
111## 批准标准
112
113- **批准**：无关键或高优先级问题
114- **警告**：仅有高优先级问题（谨慎合并）
115- **阻止**：发现关键问题
116
117## 与其他规则的集成
118
119此规则与以下规则配合：
120
121- [testing.md](testing.md) - 测试覆盖率要求
122- [security.md](security.md) - 安全检查清单
123- [git-workflow.md](git-workflow.md) - 提交标准
124- [agents.md](agents.md) - 代理委托
125
ThanhTrunggDEV/DontBeLazy · .cursor/AGENTS.md
@@ +1 @@
1# Everything Claude Code (ECC) — Agent Instructions
2
3This is a **production-ready AI coding plugin** providing 48 specialized agents, 183 skills, 79 commands, and automated hook workflows for software development.
4
5**Version:** 1.10.0
6
7## Core Principles
8
91. **Agent-First** — Delegate to specialized agents for domain tasks
102. **Test-Driven** — Write tests before implementation, 80%+ coverage required
113. **Security-First** — Never compromise on security; validate all inputs
124. **Immutability** — Always create new objects, never mutate existing ones
135. **Plan Before Execute** — Plan complex features before writing code
14
15## Available Agents
16
17| Agent | Purpose | When to Use |
18|-------|---------|-------------|
19| planner | Implementation planning | Complex features, refactoring |
20| architect | System design and scalability | Architectural decisions |
21| tdd-guide | Test-driven development | New features, bug fixes |
22| code-reviewer | Code quality and maintainability | After writing/modifying code |
23| security-reviewer | Vulnerability detection | Before commits, sensitive code |
24| build-error-resolver | Fix build/type errors | When build fails |
25| e2e-runner | End-to-end Playwright testing | Critical user flows |
26| refactor-cleaner | Dead code cleanup | Code maintenance |
27| doc-updater | Documentation and codemaps | Updating docs |
28| cpp-reviewer | C/C++ code review | C and C++ projects |
29| cpp-build-resolver | C/C++ build errors | C and C++ build failures |
30| docs-lookup | Documentation lookup via Context7 | API/docs questions |
31| go-reviewer | Go code review | Go projects |
32| go-build-resolver | Go build errors | Go build failures |
33| kotlin-reviewer | Kotlin code review | Kotlin/Android/KMP projects |
34| kotlin-build-resolver | Kotlin/Gradle build errors | Kotlin build failures |
35| database-reviewer | PostgreSQL/Supabase specialist | Schema design, query optimization |
36| python-reviewer | Python code review | Python projects |
37| java-reviewer | Java and Spring Boot code review | Java/Spring Boot projects |
38| java-build-resolver | Java/Maven/Gradle build errors | Java build failures |
39| loop-operator | Autonomous loop execution | Run loops safely, monitor stalls, intervene |
40| harness-optimizer | Harness config tuning | Reliability, cost, throughput |
41| rust-reviewer | Rust code review | Rust projects |
42| rust-build-resolver | Rust build errors | Rust build failures |
43| pytorch-build-resolver | PyTorch runtime/CUDA/training errors | PyTorch build/training failures |
44| typescript-reviewer | TypeScript/JavaScript code review | TypeScript/JavaScript projects |
45
46## Agent Orchestration
47
48Use agents proactively without user prompt:
49- Complex feature requests → **planner**
50- Code just written/modified → **code-reviewer**
51- Bug fix or new feature → **tdd-guide**
52- Architectural decision → **architect**
53- Security-sensitive code → **security-reviewer**
54- Autonomous loops / loop monitoring → **loop-operator**
55- Harness config reliability and cost → **harness-optimizer**
56
57Use parallel execution for independent operations — launch multiple agents simultaneously.
58
59## Security Guidelines
60
61**Before ANY commit:**
62- No hardcoded secrets (API keys, passwords, tokens)
63- All user inputs validated
64- SQL injection prevention (parameterized queries)
65- XSS prevention (sanitized HTML)
66- CSRF protection enabled
67- Authentication/authorization verified
68- Rate limiting on all endpoints
69- Error messages don't leak sensitive data
70
71**Secret management:** NEVER hardcode secrets. Use environment variables or a secret manager. Validate required secrets at startup. Rotate any exposed secrets immediately.
72
73**If security issue found:** STOP → use security-reviewer agent → fix CRITICAL issues → rotate exposed secrets → review codebase for similar issues.
74
75## Coding Style
76
77**Immutability (CRITICAL):** Always create new objects, never mutate. Return new copies with changes applied.
78
79**File organization:** Many small files over few large ones. 200-400 lines typical, 800 max. Organize by feature/domain, not by type. High cohesion, low coupling.
80
81**Error handling:** Handle errors at every level. Provide user-friendly messages in UI code. Log detailed context server-side. Never silently swallow errors.
82
83**Input validation:** Validate all user input at system boundaries. Use schema-based validation. Fail fast with clear messages. Never trust external data.
84
85**Code quality checklist:**
86- Functions small (<50 lines), files focused (<800 lines)
87- No deep nesting (>4 levels)
88- Proper error handling, no hardcoded values
89- Readable, well-named identifiers
90
91## Testing Requirements
92
93**Minimum coverage: 80%**
94
95Test types (all required):
961. **Unit tests** — Individual functions, utilities, components
972. **Integration tests** — API endpoints, database operations
983. **E2E tests** — Critical user flows
99
100**TDD workflow (mandatory):**
1011. Write test first (RED) — test should FAIL
1022. Write minimal implementation (GREEN) — test should PASS
1033. Refactor (IMPROVE) — verify coverage 80%+
104
105Troubleshoot failures: check test isolation → verify mocks → fix implementation (not tests, unless tests are wrong).
106
107## Development Workflow
108
1091. **Plan** — Use planner agent, identify dependencies and risks, break into phases
1102. **TDD** — Use tdd-guide agent, write tests first, implement, refactor
1113. **Review** — Use code-reviewer agent immediately, address CRITICAL/HIGH issues
1124. **Capture knowledge in the right place**
113 - Personal debugging notes, preferences, and temporary context → auto memory
114 - Team/project knowledge (architecture decisions, API changes, runbooks) → the project's existing docs structure
115 - If the current task already produces the relevant docs or code comments, do not duplicate the same information elsewhere
116 - If there is no obvious project doc location, ask before creating a new top-level file
1175. **Commit** — Conventional commits format, comprehensive PR summaries
118
119## Workflow Surface Policy
120
121- `skills/` is the canonical workflow surface.
122- New workflow contributions should land in `skills/` first.
123- `commands/` is a legacy slash-entry compatibility surface and should only be added or updated when a shim is still required for migration or cross-harness parity.
124
125## Git Workflow
126
127**Commit format:** `<type>: <description>` — Types: feat, fix, refactor, docs, test, chore, perf, ci
128
129**PR workflow:** Analyze full commit history → draft comprehensive summary → include test plan → push with `-u` flag.
130
131## Architecture Patterns
132
133**API response format:** Consistent envelope with success indicator, data payload, error message, and pagination metadata.
134
135**Repository pattern:** Encapsulate data access behind standard interface (findAll, findById, create, update, delete). Business logic depends on abstract interface, not storage mechanism.
136
137**Skeleton projects:** Search for battle-tested templates, evaluate with parallel agents (security, extensibility, relevance), clone best match, iterate within proven structure.
138
139## Performance
140
141**Context management:** Avoid last 20% of context window for large refactoring and multi-file features. Lower-sensitivity tasks (single edits, docs, simple fixes) tolerate higher utilization.
142
143**Build troubleshooting:** Use build-error-resolver agent → analyze errors → fix incrementally → verify after each fix.
144
145## Project Structure
146
147```
148agents/ — 48 specialized subagents
149skills/ — 183 workflow skills and domain knowledge
150commands/ — 79 slash commands
151hooks/ — Trigger-based automations
152rules/ — Always-follow guidelines (common + per-language)
153scripts/ — Cross-platform Node.js utilities
154mcp-configs/ — 14 MCP server configurations
155tests/ — Test suite
156```
157
158`commands/` remains in the repo for compatibility, but the long-term direction is skills-first.
159
160## Success Metrics
161
162- All tests pass with 80%+ coverage
163- No security vulnerabilities
164- Code is readable and maintainable
165- Performance is acceptable
166- User requirements are met
167
@@ −1 +1 @@
1−# 代码审查标准
1+# Everything Claude Code (ECC) — Agent Instructions
22
3−## 目的
3+This is a **production-ready AI coding plugin** providing 48 specialized agents, 183 skills, 79 commands, and automated hook workflows for software development.
44
5−代码审查确保代码合并前的质量、安全性和可维护性。此规则定义何时以及如何进行代码审查。
5+**Version:** 1.10.0
66
7−## 何时审查
7+## Core Principles
88
9−**强制审查触发条件：**
9+1. **Agent-First** — Delegate to specialized agents for domain tasks
10+2. **Test-Driven** — Write tests before implementation, 80%+ coverage required
11+3. **Security-First** — Never compromise on security; validate all inputs
12+4. **Immutability** — Always create new objects, never mutate existing ones
13+5. **Plan Before Execute** — Plan complex features before writing code
1014
11−- 编写或修改代码后
12−- 提交到共享分支之前
13−- 更改安全敏感代码时（认证、支付、用户数据）
14−- 进行架构更改时
15−- 合并 pull request 之前
15+## Available Agents
1616
17−**审查前要求：**
17+| Agent | Purpose | When to Use |
18+|-------|---------|-------------|
19+| planner | Implementation planning | Complex features, refactoring |
20+| architect | System design and scalability | Architectural decisions |
21+| tdd-guide | Test-driven development | New features, bug fixes |
22+| code-reviewer | Code quality and maintainability | After writing/modifying code |
23+| security-reviewer | Vulnerability detection | Before commits, sensitive code |
24+| build-error-resolver | Fix build/type errors | When build fails |
25+| e2e-runner | End-to-end Playwright testing | Critical user flows |
26+| refactor-cleaner | Dead code cleanup | Code maintenance |
27+| doc-updater | Documentation and codemaps | Updating docs |
28+| cpp-reviewer | C/C++ code review | C and C++ projects |
29+| cpp-build-resolver | C/C++ build errors | C and C++ build failures |
30+| docs-lookup | Documentation lookup via Context7 | API/docs questions |
31+| go-reviewer | Go code review | Go projects |
32+| go-build-resolver | Go build errors | Go build failures |
33+| kotlin-reviewer | Kotlin code review | Kotlin/Android/KMP projects |
34+| kotlin-build-resolver | Kotlin/Gradle build errors | Kotlin build failures |
35+| database-reviewer | PostgreSQL/Supabase specialist | Schema design, query optimization |
36+| python-reviewer | Python code review | Python projects |
37+| java-reviewer | Java and Spring Boot code review | Java/Spring Boot projects |
38+| java-build-resolver | Java/Maven/Gradle build errors | Java build failures |
39+| loop-operator | Autonomous loop execution | Run loops safely, monitor stalls, intervene |
40+| harness-optimizer | Harness config tuning | Reliability, cost, throughput |
41+| rust-reviewer | Rust code review | Rust projects |
42+| rust-build-resolver | Rust build errors | Rust build failures |
43+| pytorch-build-resolver | PyTorch runtime/CUDA/training errors | PyTorch build/training failures |
44+| typescript-reviewer | TypeScript/JavaScript code review | TypeScript/JavaScript projects |
1845
19−在请求审查之前，确保：
46+## Agent Orchestration
2047
21−- 所有自动化检查（CI/CD）已通过
22−- 合并冲突已解决
23−- 分支已与目标分支同步
48+Use agents proactively without user prompt:
49+- Complex feature requests → **planner**
50+- Code just written/modified → **code-reviewer**
51+- Bug fix or new feature → **tdd-guide**
52+- Architectural decision → **architect**
53+- Security-sensitive code → **security-reviewer**
54+- Autonomous loops / loop monitoring → **loop-operator**
55+- Harness config reliability and cost → **harness-optimizer**
2456
25−## 审查检查清单
57+Use parallel execution for independent operations — launch multiple agents simultaneously.
2658
27−在标记代码完成之前：
59+## Security Guidelines
2860
29−- [ ] 代码可读且命名良好
30−- [ ] 函数聚焦（<50 行）
31−- [ ] 文件内聚（<800 行）
32−- [ ] 无深层嵌套（>4 层）
33−- [ ] 错误显式处理
34−- [ ] 无硬编码密钥或凭据
35−- [ ] 无 console.log 或调试语句
36−- [ ] 新功能有测试
37−- [ ] 测试覆盖率满足 80% 最低要求
61+**Before ANY commit:**
62+- No hardcoded secrets (API keys, passwords, tokens)
63+- All user inputs validated
64+- SQL injection prevention (parameterized queries)
65+- XSS prevention (sanitized HTML)
66+- CSRF protection enabled
67+- Authentication/authorization verified
68+- Rate limiting on all endpoints
69+- Error messages don't leak sensitive data
3870
39−## 安全审查触发条件
71+**Secret management:** NEVER hardcode secrets. Use environment variables or a secret manager. Validate required secrets at startup. Rotate any exposed secrets immediately.
4072
41−**停止并使用 security-reviewer 代理当：**
73+**If security issue found:** STOP → use security-reviewer agent → fix CRITICAL issues → rotate exposed secrets → review codebase for similar issues.
4274
43−- 认证或授权代码
44−- 用户输入处理
45−- 数据库查询
46−- 文件系统操作
47−- 外部 API 调用
48−- 加密操作
49−- 支付或金融代码
75+## Coding Style
5076
51−## 审查严重级别
77+**Immutability (CRITICAL):** Always create new objects, never mutate. Return new copies with changes applied.
5278
53−| 级别 | 含义 | 行动 |
54−|-------|---------|--------|
55−| CRITICAL（关键） | 安全漏洞或数据丢失风险 | **阻止** - 合并前必须修复 |
56−| HIGH（高） | Bug 或重大质量问题 | **警告** - 合并前应修复 |
57−| MEDIUM（中） | 可维护性问题 | **信息** - 考虑修复 |
58−| LOW（低） | 风格或次要建议 | **注意** - 可选 |
79+**File organization:** Many small files over few large ones. 200-400 lines typical, 800 max. Organize by feature/domain, not by type. High cohesion, low coupling.
5980
60−## 代理使用
81+**Error handling:** Handle errors at every level. Provide user-friendly messages in UI code. Log detailed context server-side. Never silently swallow errors.
6182
62−使用这些代理进行代码审查：
83+**Input validation:** Validate all user input at system boundaries. Use schema-based validation. Fail fast with clear messages. Never trust external data.
6384
64−| 代理 | 用途 |
65−|-------|--------|
66−| **code-reviewer** | 通用代码质量、模式、最佳实践 |
67−| **security-reviewer** | 安全漏洞、OWASP Top 10 |
68−| **typescript-reviewer** | TypeScript/JavaScript 特定问题 |
69−| **python-reviewer** | Python 特定问题 |
70−| **go-reviewer** | Go 特定问题 |
71−| **rust-reviewer** | Rust 特定问题 |
85+**Code quality checklist:**
86+- Functions small (<50 lines), files focused (<800 lines)
87+- No deep nesting (>4 levels)
88+- Proper error handling, no hardcoded values
89+- Readable, well-named identifiers
7290
73−## 审查工作流
91+## Testing Requirements
7492
75−```
76−1. 运行 git diff 了解更改
77−2. 先检查安全检查清单
78−3. 审查代码质量检查清单
79−4. 运行相关测试
80−5. 验证覆盖率 >= 80%
81−6. 使用适当的代理进行详细审查
82−```
93+**Minimum coverage: 80%**
8394
84−## 常见问题捕获
95+Test types (all required):
96+1. **Unit tests** — Individual functions, utilities, components
97+2. **Integration tests** — API endpoints, database operations
98+3. **E2E tests** — Critical user flows
8599
86−### 安全
100+**TDD workflow (mandatory):**
101+1. Write test first (RED) — test should FAIL
102+2. Write minimal implementation (GREEN) — test should PASS
103+3. Refactor (IMPROVE) — verify coverage 80%+
87104
88−- 硬编码凭据（API 密钥、密码、令牌）
89−- SQL 注入（查询中的字符串拼接）
90−- XSS 漏洞（未转义的用户输入）
91−- 路径遍历（未净化的文件路径）
92−- CSRF 保护缺失
93−- 认证绕过
105+Troubleshoot failures: check test isolation → verify mocks → fix implementation (not tests, unless tests are wrong).
94106
95−### 代码质量
107+## Development Workflow
96108
97−- 大函数（>50 行）- 拆分为更小的
98−- 大文件（>800 行）- 提取模块
99−- 深层嵌套（>4 层）- 使用提前返回
100−- 缺少错误处理 - 显式处理
101−- 变更模式 - 优先使用不可变操作
102−- 缺少测试 - 添加测试覆盖
109+1. **Plan** — Use planner agent, identify dependencies and risks, break into phases
110+2. **TDD** — Use tdd-guide agent, write tests first, implement, refactor
111+3. **Review** — Use code-reviewer agent immediately, address CRITICAL/HIGH issues
112+4. **Capture knowledge in the right place**
113+ - Personal debugging notes, preferences, and temporary context → auto memory
114+ - Team/project knowledge (architecture decisions, API changes, runbooks) → the project's existing docs structure
115+ - If the current task already produces the relevant docs or code comments, do not duplicate the same information elsewhere
116+ - If there is no obvious project doc location, ask before creating a new top-level file
117+5. **Commit** — Conventional commits format, comprehensive PR summaries
103118
104−### 性能
119+## Workflow Surface Policy
105120
106−- N+1 查询 - 使用 JOIN 或批处理
107−- 缺少分页 - 给查询添加 LIMIT
108−- 无界查询 - 添加约束
109−- 缺少缓存 - 缓存昂贵操作
121+- `skills/` is the canonical workflow surface.
122+- New workflow contributions should land in `skills/` first.
123+- `commands/` is a legacy slash-entry compatibility surface and should only be added or updated when a shim is still required for migration or cross-harness parity.
110124
111−## 批准标准
125+## Git Workflow
112126
113−- **批准**：无关键或高优先级问题
114−- **警告**：仅有高优先级问题（谨慎合并）
115−- **阻止**：发现关键问题
127+**Commit format:** `<type>: <description>` — Types: feat, fix, refactor, docs, test, chore, perf, ci
116128
117−## 与其他规则的集成
129+**PR workflow:** Analyze full commit history → draft comprehensive summary → include test plan → push with `-u` flag.
118130
119−此规则与以下规则配合：
131+## Architecture Patterns
120132
121−- [testing.md](testing.md) - 测试覆盖率要求
122−- [security.md](security.md) - 安全检查清单
123−- [git-workflow.md](git-workflow.md) - 提交标准
124−- [agents.md](agents.md) - 代理委托
133+**API response format:** Consistent envelope with success indicator, data payload, error message, and pagination metadata.
134+
135+**Repository pattern:** Encapsulate data access behind standard interface (findAll, findById, create, update, delete). Business logic depends on abstract interface, not storage mechanism.
136+
137+**Skeleton projects:** Search for battle-tested templates, evaluate with parallel agents (security, extensibility, relevance), clone best match, iterate within proven structure.
138+
139+## Performance
140+
141+**Context management:** Avoid last 20% of context window for large refactoring and multi-file features. Lower-sensitivity tasks (single edits, docs, simple fixes) tolerate higher utilization.
142+
143+**Build troubleshooting:** Use build-error-resolver agent → analyze errors → fix incrementally → verify after each fix.
144+
145+## Project Structure
146+
147+```
148+agents/ — 48 specialized subagents
149+skills/ — 183 workflow skills and domain knowledge
150+commands/ — 79 slash commands
151+hooks/ — Trigger-based automations
152+rules/ — Always-follow guidelines (common + per-language)
153+scripts/ — Cross-platform Node.js utilities
154+mcp-configs/ — 14 MCP server configurations
155+tests/ — Test suite
156+```
157+
158+`commands/` remains in the repo for compatibility, but the long-term direction is skills-first.
159+
160+## Success Metrics
161+
162+- All tests pass with 80%+ coverage
163+- No security vulnerabilities
164+- Code is readable and maintainable
165+- Performance is acceptable
166+- User requirements are met
125167
