| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 7 | 14 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 1 | 1 | 7 | 11% |
What each file covers
Sections
0 shared · 7 only in A · 14 only in B- − Web Design Quality Standards
- − Anti-Template Policy
- − Banned Patterns
- − Required Qualities
- − Before Writing Frontend Code
- − Worthwhile Style Directions
- − Component Checklist
- + 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 · 1 only in A · 7 only in B- − ui
- + build
- + test
- + architecture
- + git-pr
- + security
- + performance
- + agent-behaviour
- code-style
Line diff
ThanhTrunggDEV/DontBeLazy · .cursor/rules/web-design-quality.mdc
@@ −1 @@
1> This file extends [common/patterns.md](../common/patterns.md) with web-specific design-quality guidance.
2
3# Web Design Quality Standards
4
5## Anti-Template Policy
6
7Do not ship generic template-looking UI. Frontend output should look intentional, opinionated, and specific to the product.
8
9### Banned Patterns
10
11- Default card grids with uniform spacing and no hierarchy
12- Stock hero section with centered headline, gradient blob, and generic CTA
13- Unmodified library defaults passed off as finished design
14- Flat layouts with no layering, depth, or motion
15- Uniform radius, spacing, and shadows across every component
16- Safe gray-on-white styling with one decorative accent color
17- Dashboard-by-numbers layouts with sidebar + cards + charts and no point of view
18- Default font stacks used without a deliberate reason
19
20### Required Qualities
21
22Every meaningful frontend surface should demonstrate at least four of these:
23
241. Clear hierarchy through scale contrast
252. Intentional rhythm in spacing, not uniform padding everywhere
263. Depth or layering through overlap, shadows, surfaces, or motion
274. Typography with character and a real pairing strategy
285. Color used semantically, not just decoratively
296. Hover, focus, and active states that feel designed
307. Grid-breaking editorial or bento composition where appropriate
318. Texture, grain, or atmosphere when it fits the visual direction
329. Motion that clarifies flow instead of distracting from it
3310. Data visualization treated as part of the design system, not an afterthought
34
35## Before Writing Frontend Code
36
371. Pick a specific style direction. Avoid vague defaults like "clean minimal".
382. Define a palette intentionally.
393. Choose typography deliberately.
404. Gather at least a small set of real references.
415. Use ECC design/frontend skills where relevant.
42
43## Worthwhile Style Directions
44
45- Editorial / magazine
46- Neo-brutalism
47- Glassmorphism with real depth
48- Dark luxury or light luxury with disciplined contrast
49- Bento layouts
50- Scrollytelling
51- 3D integration
52- Swiss / International
53- Retro-futurism
54
55Do not default to dark mode automatically. Choose the visual direction the product actually wants.
56
57## Component Checklist
58
59- [ ] Does it avoid looking like a default Tailwind or shadcn template?
60- [ ] Does it have intentional hover/focus/active states?
61- [ ] Does it use hierarchy rather than uniform emphasis?
62- [ ] Would this look believable in a real product screenshot?
63- [ ] If it supports both themes, do both light and dark feel intentional?
64
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−> This file extends [common/patterns.md](../common/patterns.md) with web-specific design-quality guidance.
1+# Everything Claude Code (ECC) — Agent Instructions
22
3−# Web Design Quality Standards
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−## Anti-Template Policy
5+**Version:** 1.10.0
66
7−Do not ship generic template-looking UI. Frontend output should look intentional, opinionated, and specific to the product.
7+## Core Principles
88
9−### Banned Patterns
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−- Default card grids with uniform spacing and no hierarchy
12−- Stock hero section with centered headline, gradient blob, and generic CTA
13−- Unmodified library defaults passed off as finished design
14−- Flat layouts with no layering, depth, or motion
15−- Uniform radius, spacing, and shadows across every component
16−- Safe gray-on-white styling with one decorative accent color
17−- Dashboard-by-numbers layouts with sidebar + cards + charts and no point of view
18−- Default font stacks used without a deliberate reason
15+## Available Agents
1916
20−### Required Qualities
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 |
2145
22−Every meaningful frontend surface should demonstrate at least four of these:
46+## Agent Orchestration
2347
24−1. Clear hierarchy through scale contrast
25−2. Intentional rhythm in spacing, not uniform padding everywhere
26−3. Depth or layering through overlap, shadows, surfaces, or motion
27−4. Typography with character and a real pairing strategy
28−5. Color used semantically, not just decoratively
29−6. Hover, focus, and active states that feel designed
30−7. Grid-breaking editorial or bento composition where appropriate
31−8. Texture, grain, or atmosphere when it fits the visual direction
32−9. Motion that clarifies flow instead of distracting from it
33−10. Data visualization treated as part of the design system, not an afterthought
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**
3456
35−## Before Writing Frontend Code
57+Use parallel execution for independent operations — launch multiple agents simultaneously.
3658
37−1. Pick a specific style direction. Avoid vague defaults like "clean minimal".
38−2. Define a palette intentionally.
39−3. Choose typography deliberately.
40−4. Gather at least a small set of real references.
41−5. Use ECC design/frontend skills where relevant.
59+## Security Guidelines
4260
43−## Worthwhile Style Directions
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
4470
45−- Editorial / magazine
46−- Neo-brutalism
47−- Glassmorphism with real depth
48−- Dark luxury or light luxury with disciplined contrast
49−- Bento layouts
50−- Scrollytelling
51−- 3D integration
52−- Swiss / International
53−- Retro-futurism
71+**Secret management:** NEVER hardcode secrets. Use environment variables or a secret manager. Validate required secrets at startup. Rotate any exposed secrets immediately.
5472
55−Do not default to dark mode automatically. Choose the visual direction the product actually wants.
73+**If security issue found:** STOP → use security-reviewer agent → fix CRITICAL issues → rotate exposed secrets → review codebase for similar issues.
5674
57−## Component Checklist
75+## Coding Style
5876
59−- [ ] Does it avoid looking like a default Tailwind or shadcn template?
60−- [ ] Does it have intentional hover/focus/active states?
61−- [ ] Does it use hierarchy rather than uniform emphasis?
62−- [ ] Would this look believable in a real product screenshot?
63−- [ ] If it supports both themes, do both light and dark feel intentional?
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+
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
99+
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%+
104+
105+Troubleshoot failures: check test isolation → verify mocks → fix implementation (not tests, unless tests are wrong).
106+
107+## Development Workflow
108+
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
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+```
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
64167
