Code Review Standards
Skill Profile
(Select at least one profile to enable specific modules)
Overview
Code Review Standards define how teams review code to catch bugs, share knowledge, maintain quality, and ensure consistency. Good code reviews make teams stronger.
Core Principle: "Code review is about learning, not judging. Review the code, not the person."
Why This Matters
Core Concepts & Rules
1. Core Principles
- Follow established patterns and conventions
- Maintain consistency across codebase
- Document decisions and trade-offs
2. Implementation Guidelines
- Start with the simplest viable solution
- Iterate based on feedback and requirements
- Test thoroughly before deployment
Inputs / Outputs / Contracts
- Inputs:
- <e.g., env vars, request payload, file paths, schema>
- Entry Conditions:
- <Pre-requisites: e.g., Repo initialized, DB running, specific branch checked out>
- Outputs:
- <e.g., artifacts (PR diff, docs, tests, dashboard JSON)>
- Artifacts Required (Deliverables):
- <e.g., Code Diff, Unit Tests, Migration Script, API Docs>
- Acceptance Evidence:
- <e.g., Test Report (screenshot/log), Benchmark Result, Security Scan Report>
- Success Criteria:
- <e.g., p95 < 300ms, coverage ≥ 80%>
Skill Composition
- Depends on: None
- Compatible with: None
- Conflicts with: None
- Related Skills: None
Quick Start
Assumptions
- Team uses Git for version control
- Pull requests are used for code changes
- Team has defined coding standards
- Automated tests are available
Compatibility
- Works with GitHub, GitLab, Bitbucket
- Language-agnostic review principles
- Can be adapted to any team size
Test Scenario Matrix
| Scenario |
Expected Behavior |
Notes |
| Small PR (<200 lines) |
Quick review (2-4 hours) |
Easy to review thoroughly |
| Large PR (>500 lines) |
Request to break up |
Hard to review thoroughly |
| Security vulnerability |
Blocking comment |
Must fix before merge |
| Missing tests |
Important comment |
Should add tests |
| Style issue |
Suggestion |
Nice to have |
| Good code |
Praise |
Positive reinforcement |
Technical Guardrails & Security Threat Model
1. Security & Privacy (Threat Model)
- Top Threats: Injection attacks, authentication bypass, data exposure
2. Performance & Resources
3. Architecture & Scalability
4. Observability & Reliability
Agent Directives & Error Recovery
(ข้อกำหนดสำหรับ AI Agent ในการคิดและแก้ปัญหาเมื่อเกิดข้อผิดพลาด)
- Thinking Process: Analyze root cause before fixing. Do not brute-force.
- Fallback Strategy: Stop after 3 failed test attempts. Output root cause and ask for human intervention/clarification.
- Self-Review: Check against Guardrails & Anti-patterns before finalizing.
- Output Constraints: Output ONLY the modified code block. Do not explain unless asked.
Definition of Done
Anti-patterns / Pitfalls
- ⛔ Don't: Log PII, catch-all exception, N+1 queries
- ⚠️ Watch out for: Common symptoms and quick fixes
- 💡 Instead: Use proper error handling, pagination, and logging
Reference Links
Versioning & Changelog
- Version: 1.0.0
- Changelog:
- 2026-02-22: Initial version with complete template structure
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: code-review-standards-33description: Code Review Standards define how teams review code to catch bugs, share Use when this capability is needed.4---56# Code Review Standards78## Skill Profile9*(Select at least one profile to enable specific modules)*10- [ ] **DevOps**11- [x] **Backend**12- [ ] **Frontend**13- [ ] **AI-RAG**14- [ ] **Security Critical**1516## Overview17Code Review Standards define how teams review code to catch bugs, share knowledge, maintain quality, and ensure consistency. Good code reviews make teams stronger.1819**Core Principle**: "Code review is about learning, not judging. Review the code, not the person."2021---2223## Why This Matters24- **<Benefit>**: <short explanation>25- **<Benefit>**: <short explanation>26- **<Benefit>**: <short explanation>2728## Core Concepts & Rules2930### 1. Core Principles31- Follow established patterns and conventions32- Maintain consistency across codebase33- Document decisions and trade-offs3435### 2. Implementation Guidelines36- Start with the simplest viable solution37- Iterate based on feedback and requirements38- Test thoroughly before deployment394041## Inputs / Outputs / Contracts42* **Inputs**:43 - <e.g., env vars, request payload, file paths, schema>44* **Entry Conditions**:45 - <Pre-requisites: e.g., Repo initialized, DB running, specific branch checked out>46* **Outputs**:47 - <e.g., artifacts (PR diff, docs, tests, dashboard JSON)>48* **Artifacts Required (Deliverables)**:49 - <e.g., Code Diff, Unit Tests, Migration Script, API Docs>50* **Acceptance Evidence**:51 - <e.g., Test Report (screenshot/log), Benchmark Result, Security Scan Report>52* **Success Criteria**:53 - <e.g., p95 < 300ms, coverage ≥ 80%>5455## Skill Composition56* **Depends on**: None57* **Compatible with**: None58* **Conflicts with**: None59* **Related Skills**: None6061## Quick Start62#6364## Assumptions65- Team uses Git for version control66- Pull requests are used for code changes67- Team has defined coding standards68- Automated tests are available6970## Compatibility71- Works with GitHub, GitLab, Bitbucket72- Language-agnostic review principles73- Can be adapted to any team size7475---7677## Test Scenario Matrix78| Scenario | Expected Behavior | Notes |79|----------|-------------------|-------|80| Small PR (<200 lines) | Quick review (2-4 hours) | Easy to review thoroughly |81| Large PR (>500 lines) | Request to break up | Hard to review thoroughly |82| Security vulnerability | Blocking comment | Must fix before merge |83| Missing tests | Important comment | Should add tests |84| Style issue | Suggestion | Nice to have |85| Good code | Praise | Positive reinforcement |8687---8889## Technical Guardrails & Security Threat Model9091### 1. Security & Privacy (Threat Model)92* **Top Threats**: Injection attacks, authentication bypass, data exposure93- [ ] **Data Handling**: Sanitize all user inputs to prevent Injection attacks. Never log raw PII94- [ ] **Secrets Management**: No hardcoded API keys. Use Env Vars/Secrets Manager95- [ ] **Authorization**: Validate user permissions before state changes9697### 2. Performance & Resources98- [ ] **Execution Efficiency**: Consider time complexity for algorithms99- [ ] **Memory Management**: Use streams/pagination for large data100- [ ] **Resource Cleanup**: Close DB connections/file handlers in finally blocks101102### 3. Architecture & Scalability103- [ ] **Design Pattern**: Follow SOLID principles, use Dependency Injection104- [ ] **Modularity**: Decouple logic from UI/Frameworks105106### 4. Observability & Reliability107- [ ] **Logging Standards**: Structured JSON, include trace IDs `request_id`108- [ ] **Metrics**: Track `error_rate`, `latency`, `queue_depth`109- [ ] **Error Handling**: Standardized error codes, no bare except110- [ ] **Observability Artifacts**:111 - **Log Fields**: timestamp, level, message, request_id112 - **Metrics**: request_count, error_count, response_time113 - **Dashboards/Alerts**: High Error Rate > 5%114115116## Agent Directives & Error Recovery117*(ข้อกำหนดสำหรับ AI Agent ในการคิดและแก้ปัญหาเมื่อเกิดข้อผิดพลาด)*118119- **Thinking Process**: Analyze root cause before fixing. Do not brute-force.120- **Fallback Strategy**: Stop after 3 failed test attempts. Output root cause and ask for human intervention/clarification.121- **Self-Review**: Check against Guardrails & Anti-patterns before finalizing.122- **Output Constraints**: Output ONLY the modified code block. Do not explain unless asked.123124125## Definition of Done126- [ ] Review process documented127- [ ] PR template with checklist128- [ ] Review checklist available129- [ ] Comment guidelines defined130- [ ] Severity levels established131- [ ] PR size guidelines set132- [ ] Turnaround SLAs defined133- [ ] Automated checks in place134- [ ] Metrics dashboard configured135- [ ] Team trained on standards136137---138139## Anti-patterns / Pitfalls140141* ⛔ **Don't**: Log PII, catch-all exception, N+1 queries142* ⚠️ **Watch out for**: Common symptoms and quick fixes143* 💡 **Instead**: Use proper error handling, pagination, and logging144145146## Reference Links147- [Google's Code Review Guide](https://google.github.io/eng-practices/review/)148- [GitHub's Pull Request Best Practices](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)149- [Atlassian's Code Review Guide](https://www.atlassian.com/agile/software-development/code-reviews)150151---152153## Versioning & Changelog154155* **Version**: 1.0.0156* **Changelog**:157 - 2026-02-22: Initial version with complete template structure158159---160> Converted and distributed by [TomeVault](https://tomevault.io/claim/amnadtaowsoam) — claim your Tome and manage your conversions.161<!-- tomevault:4.0:skill_md:2026-04-13 -->