| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 1 | 13 | 13 | 4% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 5 | 3 | 2 | 50% |
What each file covers
Sections
1 shared · 13 only in A · 13 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
- − Project Structure
- − Success Metrics
- + Code Review Standards
- + Purpose
- + When to Review
- + Review Checklist
- + Security Review Triggers
- + Review Severity Levels
- + Agent Usage
- + Review Workflow
- + Common Issues to Catch
- + Security
- + Code Quality
- + Approval Criteria
- + Integration with Other Rules
- Performance
Commands
neither file has anySection tags
5 shared · 3 only in A · 2 only in B- − build
- − test
- − architecture
- + testing-strategy
- + do-not
- code-style
- git-pr
- security
- performance
- agent-behaviour
Line diff
ThanhTrunggDEV/DontBeLazy · .agent/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
ThanhTrunggDEV/DontBeLazy · .cursor/rules/common-code-review.mdc
@@ +1 @@
1# Code Review Standards
2
3## Purpose
4
5Code review ensures quality, security, and maintainability before code is merged. This rule defines when and how to conduct code reviews.
6
7## When to Review
8
9**MANDATORY review triggers:**
10
11- After writing or modifying code
12- Before any commit to shared branches
13- When security-sensitive code is changed (auth, payments, user data)
14- When architectural changes are made
15- Before merging pull requests
16
17**Pre-Review Requirements:**
18
19Before requesting review, ensure:
20
21- All automated checks (CI/CD) are passing
22- Merge conflicts are resolved
23- Branch is up to date with target branch
24
25## Review Checklist
26
27Before marking code complete:
28
29- [ ] Code is readable and well-named
30- [ ] Functions are focused (<50 lines)
31- [ ] Files are cohesive (<800 lines)
32- [ ] No deep nesting (>4 levels)
33- [ ] Errors are handled explicitly
34- [ ] No hardcoded secrets or credentials
35- [ ] No console.log or debug statements
36- [ ] Tests exist for new functionality
37- [ ] Test coverage meets 80% minimum
38
39## Security Review Triggers
40
41**STOP and use security-reviewer agent when:**
42
43- Authentication or authorization code
44- User input handling
45- Database queries
46- File system operations
47- External API calls
48- Cryptographic operations
49- Payment or financial code
50
51## Review Severity Levels
52
53| Level | Meaning | Action |
54|-------|---------|--------|
55| CRITICAL | Security vulnerability or data loss risk | **BLOCK** - Must fix before merge |
56| HIGH | Bug or significant quality issue | **WARN** - Should fix before merge |
57| MEDIUM | Maintainability concern | **INFO** - Consider fixing |
58| LOW | Style or minor suggestion | **NOTE** - Optional |
59
60## Agent Usage
61
62Use these agents for code review:
63
64| Agent | Purpose |
65|-------|---------|
66| **code-reviewer** | General code quality, patterns, best practices |
67| **security-reviewer** | Security vulnerabilities, OWASP Top 10 |
68| **typescript-reviewer** | TypeScript/JavaScript specific issues |
69| **python-reviewer** | Python specific issues |
70| **go-reviewer** | Go specific issues |
71| **rust-reviewer** | Rust specific issues |
72
73## Review Workflow
74
75```
761. Run git diff to understand changes
772. Check security checklist first
783. Review code quality checklist
794. Run relevant tests
805. Verify coverage >= 80%
816. Use appropriate agent for detailed review
82```
83
84## Common Issues to Catch
85
86### Security
87
88- Hardcoded credentials (API keys, passwords, tokens)
89- SQL injection (string concatenation in queries)
90- XSS vulnerabilities (unescaped user input)
91- Path traversal (unsanitized file paths)
92- CSRF protection missing
93- Authentication bypasses
94
95### Code Quality
96
97- Large functions (>50 lines) - split into smaller
98- Large files (>800 lines) - extract modules
99- Deep nesting (>4 levels) - use early returns
100- Missing error handling - handle explicitly
101- Mutation patterns - prefer immutable operations
102- Missing tests - add test coverage
103
104### Performance
105
106- N+1 queries - use JOINs or batching
107- Missing pagination - add LIMIT to queries
108- Unbounded queries - add constraints
109- Missing caching - cache expensive operations
110
111## Approval Criteria
112
113- **Approve**: No CRITICAL or HIGH issues
114- **Warning**: Only HIGH issues (merge with caution)
115- **Block**: CRITICAL issues found
116
117## Integration with Other Rules
118
119This rule works with:
120
121- [testing.md](testing.md) - Test coverage requirements
122- [security.md](security.md) - Security checklist
123- [git-workflow.md](git-workflow.md) - Commit standards
124- [agents.md](agents.md) - Agent delegation
125
@@ −1 +1 @@
1−# Everything Claude Code (ECC) — Agent Instructions
1+# Code Review Standards
22
3−This is a **production-ready AI coding plugin** providing 48 specialized agents, 183 skills, 79 commands, and automated hook workflows for software development.
3+## Purpose
44
5−**Version:** 1.10.0
5+Code review ensures quality, security, and maintainability before code is merged. This rule defines when and how to conduct code reviews.
66
7−## Core Principles
7+## When to Review
88
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
9+**MANDATORY review triggers:**
1410
15−## Available Agents
11+- After writing or modifying code
12+- Before any commit to shared branches
13+- When security-sensitive code is changed (auth, payments, user data)
14+- When architectural changes are made
15+- Before merging pull requests
1616
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 |
17+**Pre-Review Requirements:**
4518
46−## Agent Orchestration
19+Before requesting review, ensure:
4720
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**
21+- All automated checks (CI/CD) are passing
22+- Merge conflicts are resolved
23+- Branch is up to date with target branch
5624
57−Use parallel execution for independent operations — launch multiple agents simultaneously.
25+## Review Checklist
5826
59−## Security Guidelines
27+Before marking code complete:
6028
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
29+- [ ] Code is readable and well-named
30+- [ ] Functions are focused (<50 lines)
31+- [ ] Files are cohesive (<800 lines)
32+- [ ] No deep nesting (>4 levels)
33+- [ ] Errors are handled explicitly
34+- [ ] No hardcoded secrets or credentials
35+- [ ] No console.log or debug statements
36+- [ ] Tests exist for new functionality
37+- [ ] Test coverage meets 80% minimum
7038
71−**Secret management:** NEVER hardcode secrets. Use environment variables or a secret manager. Validate required secrets at startup. Rotate any exposed secrets immediately.
39+## Security Review Triggers
7240
73−**If security issue found:** STOP → use security-reviewer agent → fix CRITICAL issues → rotate exposed secrets → review codebase for similar issues.
41+**STOP and use security-reviewer agent when:**
7442
75−## Coding Style
43+- Authentication or authorization code
44+- User input handling
45+- Database queries
46+- File system operations
47+- External API calls
48+- Cryptographic operations
49+- Payment or financial code
7650
77−**Immutability (CRITICAL):** Always create new objects, never mutate. Return new copies with changes applied.
51+## Review Severity Levels
7852
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.
53+| Level | Meaning | Action |
54+|-------|---------|--------|
55+| CRITICAL | Security vulnerability or data loss risk | **BLOCK** - Must fix before merge |
56+| HIGH | Bug or significant quality issue | **WARN** - Should fix before merge |
57+| MEDIUM | Maintainability concern | **INFO** - Consider fixing |
58+| LOW | Style or minor suggestion | **NOTE** - Optional |
8059
81−**Error handling:** Handle errors at every level. Provide user-friendly messages in UI code. Log detailed context server-side. Never silently swallow errors.
60+## Agent Usage
8261
83−**Input validation:** Validate all user input at system boundaries. Use schema-based validation. Fail fast with clear messages. Never trust external data.
62+Use these agents for code review:
8463
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
64+| Agent | Purpose |
65+|-------|---------|
66+| **code-reviewer** | General code quality, patterns, best practices |
67+| **security-reviewer** | Security vulnerabilities, OWASP Top 10 |
68+| **typescript-reviewer** | TypeScript/JavaScript specific issues |
69+| **python-reviewer** | Python specific issues |
70+| **go-reviewer** | Go specific issues |
71+| **rust-reviewer** | Rust specific issues |
9072
91−## Testing Requirements
73+## Review Workflow
9274
93−**Minimum coverage: 80%**
75+```
76+1. Run git diff to understand changes
77+2. Check security checklist first
78+3. Review code quality checklist
79+4. Run relevant tests
80+5. Verify coverage >= 80%
81+6. Use appropriate agent for detailed review
82+```
9483
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
84+## Common Issues to Catch
9985
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%+
86+### Security
10487
105−Troubleshoot failures: check test isolation → verify mocks → fix implementation (not tests, unless tests are wrong).
88+- Hardcoded credentials (API keys, passwords, tokens)
89+- SQL injection (string concatenation in queries)
90+- XSS vulnerabilities (unescaped user input)
91+- Path traversal (unsanitized file paths)
92+- CSRF protection missing
93+- Authentication bypasses
10694
107−## Development Workflow
95+### Code Quality
10896
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
97+- Large functions (>50 lines) - split into smaller
98+- Large files (>800 lines) - extract modules
99+- Deep nesting (>4 levels) - use early returns
100+- Missing error handling - handle explicitly
101+- Mutation patterns - prefer immutable operations
102+- Missing tests - add test coverage
118103
119−## Workflow Surface Policy
104+### Performance
120105
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.
106+- N+1 queries - use JOINs or batching
107+- Missing pagination - add LIMIT to queries
108+- Unbounded queries - add constraints
109+- Missing caching - cache expensive operations
124110
125−## Git Workflow
111+## Approval Criteria
126112
127−**Commit format:** `<type>: <description>` — Types: feat, fix, refactor, docs, test, chore, perf, ci
113+- **Approve**: No CRITICAL or HIGH issues
114+- **Warning**: Only HIGH issues (merge with caution)
115+- **Block**: CRITICAL issues found
128116
129−**PR workflow:** Analyze full commit history → draft comprehensive summary → include test plan → push with `-u` flag.
117+## Integration with Other Rules
130118
131−## Architecture Patterns
119+This rule works with:
132120
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
121+- [testing.md](testing.md) - Test coverage requirements
122+- [security.md](security.md) - Security checklist
123+- [git-workflow.md](git-workflow.md) - Commit standards
124+- [agents.md](agents.md) - Agent delegation
167125
