| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 10 | 14 | 0% |
| Commands | 0 | 2 | 0 | 0% |
| Section tags | 1 | 1 | 7 | 11% |
What each file covers
Sections
0 shared · 10 only in A · 14 only in B- − Rust Coding Style
- − Formatting
- − Immutability
- − Naming
- − Ownership and Borrowing
- − Error Handling
- − Iterators Over Loops
- − Module Organization
- − Visibility
- − References
- + 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
0 shared · 2 only in A · 0 only in B- − cargo fmt
- − cargo clippy -- -D warnings
Section tags
1 shared · 1 only in A · 7 only in B- − lint-format
- + build
- + test
- + architecture
- + git-pr
- + security
- + performance
- + agent-behaviour
- code-style
Line diff
ThanhTrunggDEV/DontBeLazy · .cursor/rules/rust-coding-style.mdc
@@ −1 @@
1---
2paths:
3 - "**/*.rs"
4---
5# Rust Coding Style
6
7> This file extends [common/coding-style.md](../common/coding-style.md) with Rust-specific content.
8
9## Formatting
10
11- **rustfmt** for enforcement — always run `cargo fmt` before committing
12- **clippy** for lints — `cargo clippy -- -D warnings` (treat warnings as errors)
13- 4-space indent (rustfmt default)
14- Max line width: 100 characters (rustfmt default)
15
16## Immutability
17
18Rust variables are immutable by default — embrace this:
19
20- Use `let` by default; only use `let mut` when mutation is required
21- Prefer returning new values over mutating in place
22- Use `Cow<'_, T>` when a function may or may not need to allocate
23
24```rust
25use std::borrow::Cow;
26
27// GOOD — immutable by default, new value returned
28fn normalize(input: &str) -> Cow<'_, str> {
29 if input.contains(' ') {
30 Cow::Owned(input.replace(' ', "_"))
31 } else {
32 Cow::Borrowed(input)
33 }
34}
35
36// BAD — unnecessary mutation
37fn normalize_bad(input: &mut String) {
38 *input = input.replace(' ', "_");
39}
40```
41
42## Naming
43
44Follow standard Rust conventions:
45- `snake_case` for functions, methods, variables, modules, crates
46- `PascalCase` (UpperCamelCase) for types, traits, enums, type parameters
47- `SCREAMING_SNAKE_CASE` for constants and statics
48- Lifetimes: short lowercase (`'a`, `'de`) — descriptive names for complex cases (`'input`)
49
50## Ownership and Borrowing
51
52- Borrow (`&T`) by default; take ownership only when you need to store or consume
53- Never clone to satisfy the borrow checker without understanding the root cause
54- Accept `&str` over `String`, `&[T]` over `Vec<T>` in function parameters
55- Use `impl Into<String>` for constructors that need to own a `String`
56
57```rust
58// GOOD — borrows when ownership isn't needed
59fn word_count(text: &str) -> usize {
60 text.split_whitespace().count()
61}
62
63// GOOD — takes ownership in constructor via Into
64fn new(name: impl Into<String>) -> Self {
65 Self { name: name.into() }
66}
67
68// BAD — takes String when &str suffices
69fn word_count_bad(text: String) -> usize {
70 text.split_whitespace().count()
71}
72```
73
74## Error Handling
75
76- Use `Result<T, E>` and `?` for propagation — never `unwrap()` in production code
77- **Libraries**: define typed errors with `thiserror`
78- **Applications**: use `anyhow` for flexible error context
79- Add context with `.with_context(|| format!("failed to ..."))?`
80- Reserve `unwrap()` / `expect()` for tests and truly unreachable states
81
82```rust
83// GOOD — library error with thiserror
84#[derive(Debug, thiserror::Error)]
85pub enum ConfigError {
86 #[error("failed to read config: {0}")]
87 Io(#[from] std::io::Error),
88 #[error("invalid config format: {0}")]
89 Parse(String),
90}
91
92// GOOD — application error with anyhow
93use anyhow::Context;
94
95fn load_config(path: &str) -> anyhow::Result<Config> {
96 let content = std::fs::read_to_string(path)
97 .with_context(|| format!("failed to read {path}"))?;
98 toml::from_str(&content)
99 .with_context(|| format!("failed to parse {path}"))
100}
101```
102
103## Iterators Over Loops
104
105Prefer iterator chains for transformations; use loops for complex control flow:
106
107```rust
108// GOOD — declarative and composable
109let active_emails: Vec<&str> = users.iter()
110 .filter(|u| u.is_active)
111 .map(|u| u.email.as_str())
112 .collect();
113
114// GOOD — loop for complex logic with early returns
115for user in &users {
116 if let Some(verified) = verify_email(&user.email)? {
117 send_welcome(&verified)?;
118 }
119}
120```
121
122## Module Organization
123
124Organize by domain, not by type:
125
126```text
127src/
128├── main.rs
129├── lib.rs
130├── auth/ # Domain module
131│ ├── mod.rs
132│ ├── token.rs
133│ └── middleware.rs
134├── orders/ # Domain module
135│ ├── mod.rs
136│ ├── model.rs
137│ └── service.rs
138└── db/ # Infrastructure
139 ├── mod.rs
140 └── pool.rs
141```
142
143## Visibility
144
145- Default to private; use `pub(crate)` for internal sharing
146- Only mark `pub` what is part of the crate's public API
147- Re-export public API from `lib.rs`
148
149## References
150
151See skill: `rust-patterns` for comprehensive Rust idioms and patterns.
152
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
@@ −1 +1 @@
1−---
2−paths:
3− - "**/*.rs"
4−---
5−# Rust Coding Style
1+# Everything Claude Code (ECC) — Agent Instructions
62
7−> This file extends [common/coding-style.md](../common/coding-style.md) with Rust-specific content.
3+This is a **production-ready AI coding plugin** providing 48 specialized agents, 183 skills, 79 commands, and automated hook workflows for software development.
84
9−## Formatting
5+**Version:** 1.10.0
106
11−- **rustfmt** for enforcement — always run `cargo fmt` before committing
12−- **clippy** for lints — `cargo clippy -- -D warnings` (treat warnings as errors)
13−- 4-space indent (rustfmt default)
14−- Max line width: 100 characters (rustfmt default)
7+## Core Principles
158
16−## Immutability
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
1714
18−Rust variables are immutable by default — embrace this:
15+## Available Agents
1916
20−- Use `let` by default; only use `let mut` when mutation is required
21−- Prefer returning new values over mutating in place
22−- Use `Cow<'_, T>` when a function may or may not need to allocate
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 |
2345
24−```rust
25−use std::borrow::Cow;
46+## Agent Orchestration
2647
27−// GOOD — immutable by default, new value returned
28−fn normalize(input: &str) -> Cow<'_, str> {
29− if input.contains(' ') {
30− Cow::Owned(input.replace(' ', "_"))
31− } else {
32− Cow::Borrowed(input)
33− }
34−}
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**
3556
36−// BAD — unnecessary mutation
37−fn normalize_bad(input: &mut String) {
38− *input = input.replace(' ', "_");
39−}
40−```
57+Use parallel execution for independent operations — launch multiple agents simultaneously.
4158
42−## Naming
59+## Security Guidelines
4360
44−Follow standard Rust conventions:
45−- `snake_case` for functions, methods, variables, modules, crates
46−- `PascalCase` (UpperCamelCase) for types, traits, enums, type parameters
47−- `SCREAMING_SNAKE_CASE` for constants and statics
48−- Lifetimes: short lowercase (`'a`, `'de`) — descriptive names for complex cases (`'input`)
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
4970
50−## Ownership and Borrowing
71+**Secret management:** NEVER hardcode secrets. Use environment variables or a secret manager. Validate required secrets at startup. Rotate any exposed secrets immediately.
5172
52−- Borrow (`&T`) by default; take ownership only when you need to store or consume
53−- Never clone to satisfy the borrow checker without understanding the root cause
54−- Accept `&str` over `String`, `&[T]` over `Vec<T>` in function parameters
55−- Use `impl Into<String>` for constructors that need to own a `String`
73+**If security issue found:** STOP → use security-reviewer agent → fix CRITICAL issues → rotate exposed secrets → review codebase for similar issues.
5674
57−```rust
58−// GOOD — borrows when ownership isn't needed
59−fn word_count(text: &str) -> usize {
60− text.split_whitespace().count()
61−}
75+## Coding Style
6276
63−// GOOD — takes ownership in constructor via Into
64−fn new(name: impl Into<String>) -> Self {
65− Self { name: name.into() }
66−}
77+**Immutability (CRITICAL):** Always create new objects, never mutate. Return new copies with changes applied.
6778
68−// BAD — takes String when &str suffices
69−fn word_count_bad(text: String) -> usize {
70− text.split_whitespace().count()
71−}
72−```
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.
7380
74−## Error Handling
81+**Error handling:** Handle errors at every level. Provide user-friendly messages in UI code. Log detailed context server-side. Never silently swallow errors.
7582
76−- Use `Result<T, E>` and `?` for propagation — never `unwrap()` in production code
77−- **Libraries**: define typed errors with `thiserror`
78−- **Applications**: use `anyhow` for flexible error context
79−- Add context with `.with_context(|| format!("failed to ..."))?`
80−- Reserve `unwrap()` / `expect()` for tests and truly unreachable states
83+**Input validation:** Validate all user input at system boundaries. Use schema-based validation. Fail fast with clear messages. Never trust external data.
8184
82−```rust
83−// GOOD — library error with thiserror
84−#[derive(Debug, thiserror::Error)]
85−pub enum ConfigError {
86− #[error("failed to read config: {0}")]
87− Io(#[from] std::io::Error),
88− #[error("invalid config format: {0}")]
89− Parse(String),
90−}
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
9190
92−// GOOD — application error with anyhow
93−use anyhow::Context;
91+## Testing Requirements
9492
95−fn load_config(path: &str) -> anyhow::Result<Config> {
96− let content = std::fs::read_to_string(path)
97− .with_context(|| format!("failed to read {path}"))?;
98− toml::from_str(&content)
99− .with_context(|| format!("failed to parse {path}"))
100−}
101−```
93+**Minimum coverage: 80%**
10294
103−## Iterators Over Loops
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
10499
105−Prefer iterator chains for transformations; use loops for complex control flow:
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%+
106104
107−```rust
108−// GOOD — declarative and composable
109−let active_emails: Vec<&str> = users.iter()
110− .filter(|u| u.is_active)
111− .map(|u| u.email.as_str())
112− .collect();
105+Troubleshoot failures: check test isolation → verify mocks → fix implementation (not tests, unless tests are wrong).
113106
114−// GOOD — loop for complex logic with early returns
115−for user in &users {
116− if let Some(verified) = verify_email(&user.email)? {
117− send_welcome(&verified)?;
118− }
119−}
120−```
107+## Development Workflow
121108
122−## Module Organization
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
123118
124−Organize by domain, not by type:
119+## Workflow Surface Policy
125120
126−```text
127−src/
128−├── main.rs
129−├── lib.rs
130−├── auth/ # Domain module
131−│ ├── mod.rs
132−│ ├── token.rs
133−│ └── middleware.rs
134−├── orders/ # Domain module
135−│ ├── mod.rs
136−│ ├── model.rs
137−│ └── service.rs
138−└── db/ # Infrastructure
139− ├── mod.rs
140− └── pool.rs
141−```
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.
142124
143−## Visibility
125+## Git Workflow
144126
145−- Default to private; use `pub(crate)` for internal sharing
146−- Only mark `pub` what is part of the crate's public API
147−- Re-export public API from `lib.rs`
127+**Commit format:** `<type>: <description>` — Types: feat, fix, refactor, docs, test, chore, perf, ci
148128
149−## References
129+**PR workflow:** Analyze full commit history → draft comprehensive summary → include test plan → push with `-u` flag.
150130
151−See skill: `rust-patterns` for comprehensive Rust idioms and patterns.
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
152167
