d4ea931bf8
* feat(agents): add modular engineering rules from 2026 standards Add a rules directory with individual rule files derived from the Cal.com Engineering in 2026 and Beyond blog post. Rules are organized by section (architecture, quality, data, api, performance, testing, patterns, culture) following the Vercel agent-skills structure. Includes: - _sections.md defining rule categories and impact levels - _template.md for creating new rules - 14 individual rule files covering key engineering standards - README documenting the rules structure and usage Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * feat(agents): consolidate DI and Repository+DTO docs into rules - Move di-pattern.md content to rules/patterns-di-pattern.md - Extract Repository + DTO section from knowledge-base.md into: - rules/data-repository-methods.md (method naming conventions) - rules/data-dto-boundaries.md (DTO location and naming) - Update knowledge-base.md to reference the new rule files - Delete old di-pattern.md file Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * chore(agents): remove stub reference sections from knowledge-base.md The rules directory is self-contained with its own README, so these redirect sections are unnecessary clutter. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * refactor(agents): combine DI pattern rules into single file Merged patterns-di-pattern.md into patterns-dependency-injection.md to eliminate overlap and create one comprehensive DI guide. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
1.6 KiB
1.6 KiB
title, impact, impactDescription, tags
| title | impact | impactDescription | tags |
|---|---|---|---|
| Address All Nits Before Merging | HIGH | Prevents codebase degradation over time | quality, code-review, standards |
Address All Nits Before Merging
Impact: HIGH
Don't let PRs through with a lot of nits just to avoid being "the bad person." This is precisely how codebases become sloppy over time. Code review is not about being nice. It's about maintaining the quality standards our infrastructure demands.
Incorrect approach:
Reviewer: "This variable name could be clearer, but it's fine I guess"
Reviewer: "We usually use early returns here, but this works"
Reviewer: "Approved with minor suggestions"
// PR merged with multiple small issues
Correct approach:
Reviewer: "Please rename `d` to `userData` for clarity"
Reviewer: "Please refactor to use early returns per our standards"
Reviewer: "Requesting changes - please address before merging"
// PR updated to meet all standards before merge
The principle: Every nitpick matters. Every pattern violation matters. Address them before merging, not after. We hold each other accountable for quality because cutting corners might feel faster in the moment, but it creates problems that slow everyone down later.
Make it normal to challenge poor decisions, respectfully:
- If someone says "let's just hard-code this for now," ask "what would it take to do it the proper way the first time?"
- If someone wants to commit untested code, push back
- If someone suggests copying and pasting instead of creating a proper abstraction, call it out respectfully
Reference: Cal.com Engineering Blog