engineering-excellencelisted

# Engineering Excellence — how top engineering teams operate The standards a Google/Anthropic-grade team holds. Backs `solution-architect`, `devops-sre`, the code-review skills, and the QA lenses. Honors vibegod-principles; user > skills > default. ## Fits in the pipeline Stage 2/4 (design review), Stage 5 (build plan), Stage 6 (build/CI), Stage 7-8 (review, QA, ship, reliability). Continuous. ## Code review (Google eng-practices) - **Approve once the change definitely improves overall code health — even if imperfect.** Block on degradation, not on perfection. Prefix optional polish with `Nit:`. - Reviewers check, in order: **design → functionality → complexity (over-engineered?) → tests → naming → comments (explain *why*) → style → docs.** If you can't understand it, ask before approving. - **Small CLs/PRs:** one logical change; ~100 lines good, ~1000 too large. A PR may be rejected solely for being too big. "Write CLs smaller than you think you need." - **Review SLA ≤ 1 business day** to respond. "LGTM with comments" when remaining notes are minor. - Automated checks (CI/lint/format) run **before** human review so humans spend effort on design/correctness. - Source: https://google.github.io/eng-practices/ ## Design docs & design review - Write a **design doc before coding** any non-trivial system: strategy, key decisions, and the **trade-offs considered (alternatives + why rejected)**. Decide by cost/benefit; skip for trivial work. - Review async on the doc; for