Developer

**Judgement** A high-quality, opinionated “software engineering handbook” skill that should noticeably improve the clarity, maintainability, and reviewability of code produced with it. It is especially suited for realistic day-to-day development (debugging, tests, incremental design) rather than competitive coding or micro-optimizations. **Strengths** - Broad, coherent coverage: code quality, debugging, testing, architecture, performance, dependencies, working in legacy code, and team communication. - Emphasizes readable, behavior-driven, and testable code, which aligns well with professional practices. - Encourages systematic debugging and error handling (reproduce issues, fail fast, log context, catch specific exceptions). - Strong focus on collaboration norms (small PRs, meaningful commit messages, documenting “why”). **Key Risks / Limitations** - Guidance is intentionally generic; it doesn’t include language-, framework-, or domain-specific patterns, so it may need complementing for specialized stacks (e.g., low-latency systems, embedded, high-security domains). - Opinionated rules (e.g., “one assertion per test when possible”) may conflict with existing team conventions or house styles. - Little explicit coverage of security, concurrency, or data privacy concerns beyond general dependency hygiene. - May bias the model toward conservative, incremental changes over bold refactors or highly optimized solutions when those are actually required. **Recommended Scenarios** - Day-to-day application development where long-term maintainability and readability are priorities. - Debugging and test-writing sessions, especially when working in existing or legacy codebases. - Code review assistance and architecture discussions within teams that value pragmatic, incremental improvement. - Educational or mentoring contexts to instill solid baseline engineering habits in less-experienced developers. **Less Ideal Scenarios** - Highly specialized, performance-critical, or hardware-constrained environments where deep domain-specific strategies are required. - Teams with very strict, pre-established coding standards that differ significantly from the opinions in this skill, unless aligned deliberately.