@papi-ai/skills 0.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,368 @@
1
+ # GitHub CLI (gh) Guide for PR Reviews
2
+
3
+ This reference provides quick commands and patterns for accessing PR data using the GitHub CLI.
4
+
5
+ ## Prerequisites
6
+
7
+ Install GitHub CLI: https://cli.github.com/
8
+
9
+ Authenticate:
10
+ ```bash
11
+ gh auth login
12
+ ```
13
+
14
+ ## Basic PR Information
15
+
16
+ ### View PR Details
17
+ ```bash
18
+ gh pr view <number> --repo <owner>/<repo>
19
+
20
+ # With JSON output
21
+ gh pr view <number> --repo <owner>/<repo> --json number,title,body,state,author,headRefName,baseRefName
22
+ ```
23
+
24
+ ### View PR Diff
25
+ ```bash
26
+ gh pr diff <number> --repo <owner>/<repo>
27
+
28
+ # Save to file
29
+ gh pr diff <number> --repo <owner>/<repo> > pr_diff.patch
30
+ ```
31
+
32
+ ### List PR Files
33
+ ```bash
34
+ gh pr view <number> --repo <owner>/<repo> --json files --jq '.files[].path'
35
+ ```
36
+
37
+ ## PR Comments and Reviews
38
+
39
+ ### Get PR Comments (Review Comments on Code)
40
+ ```bash
41
+ gh api /repos/<owner>/<repo>/pulls/<number>/comments
42
+
43
+ # Paginate through all comments
44
+ gh api /repos/<owner>/<repo>/pulls/<number>/comments --paginate
45
+
46
+ # With JQ filtering
47
+ gh api /repos/<owner>/<repo>/pulls/<number>/comments --jq '.[] | {path, line, body, user: .user.login}'
48
+ ```
49
+
50
+ ### Get PR Reviews
51
+ ```bash
52
+ gh api /repos/<owner>/<repo>/pulls/<number>/reviews
53
+
54
+ # With formatted output
55
+ gh api /repos/<owner>/<repo>/pulls/<number>/reviews --jq '.[] | {state, user: .user.login, body}'
56
+ ```
57
+
58
+ ### Get Issue Comments (General PR Comments)
59
+ ```bash
60
+ gh api /repos/<owner>/<repo>/issues/<number>/comments
61
+ ```
62
+
63
+ ## Commit Information
64
+
65
+ ### List PR Commits
66
+ ```bash
67
+ gh api /repos/<owner>/<repo>/pulls/<number>/commits
68
+
69
+ # Get commit messages
70
+ gh api /repos/<owner>/<repo>/pulls/<number>/commits --jq '.[] | {sha: .sha[0:7], message: .commit.message}'
71
+
72
+ # Get latest commit SHA
73
+ gh api /repos/<owner>/<repo>/pulls/<number>/commits --jq '.[-1].sha'
74
+ ```
75
+
76
+ ### Get Commit Details
77
+ ```bash
78
+ gh api /repos/<owner>/<repo>/commits/<sha>
79
+
80
+ # Get commit diff
81
+ gh api /repos/<owner>/<repo>/commits/<sha> -H "Accept: application/vnd.github.diff"
82
+ ```
83
+
84
+ ## Branches
85
+
86
+ ### Get Branch Information
87
+ ```bash
88
+ # Source branch (head)
89
+ gh pr view <number> --repo <owner>/<repo> --json headRefName --jq '.headRefName'
90
+
91
+ # Target branch (base)
92
+ gh pr view <number> --repo <owner>/<repo> --json baseRefName --jq '.baseRefName'
93
+ ```
94
+
95
+ ### Compare Branches
96
+ ```bash
97
+ gh api /repos/<owner>/<repo>/compare/<base>...<head>
98
+
99
+ # Get files changed
100
+ gh api /repos/<owner>/<repo>/compare/<base>...<head> --jq '.files[] | {filename, status, additions, deletions}'
101
+ ```
102
+
103
+ ## Related Issues and Tickets
104
+
105
+ ### Get Linked Issues
106
+ ```bash
107
+ # Get PR body which may contain issue references
108
+ gh pr view <number> --repo <owner>/<repo> --json body --jq '.body'
109
+
110
+ # Search for issue references (#123 format)
111
+ gh pr view <number> --repo <owner>/<repo> --json body --jq '.body' | grep -oE '#[0-9]+'
112
+ ```
113
+
114
+ ### Get Issue Details
115
+ ```bash
116
+ gh issue view <number> --repo <owner>/<repo>
117
+
118
+ # JSON format
119
+ gh issue view <number> --repo <owner>/<repo> --json number,title,body,state,labels,assignees
120
+ ```
121
+
122
+ ### Get Issue Comments
123
+ ```bash
124
+ gh api /repos/<owner>/<repo>/issues/<number>/comments
125
+ ```
126
+
127
+ ## PR Status Checks
128
+
129
+ ### Get PR Status
130
+ ```bash
131
+ gh pr checks <number> --repo <owner>/<repo>
132
+
133
+ # JSON format
134
+ gh api /repos/<owner>/<repo>/commits/<sha>/status
135
+ ```
136
+
137
+ ### Get Check Runs
138
+ ```bash
139
+ gh api /repos/<owner>/<repo>/commits/<sha>/check-runs
140
+ ```
141
+
142
+ ## Adding Comments
143
+
144
+ ### Add Inline Code Comment
145
+ ```bash
146
+ gh api -X POST /repos/<owner>/<repo>/pulls/<number>/comments \
147
+ -f body="Your comment here" \
148
+ -f commit_id="<sha>" \
149
+ -f path="src/file.py" \
150
+ -f side="RIGHT" \
151
+ -f line=42
152
+ ```
153
+
154
+ ### Add Multi-line Inline Comment
155
+ ```bash
156
+ gh api -X POST /repos/<owner>/<repo>/pulls/<number>/comments \
157
+ -f body="Multi-line comment" \
158
+ -f commit_id="<sha>" \
159
+ -f path="src/file.py" \
160
+ -f side="RIGHT" \
161
+ -f start_line=40 \
162
+ -f start_side="RIGHT" \
163
+ -f line=45
164
+ ```
165
+
166
+ ### Add General PR Comment
167
+ ```bash
168
+ gh pr comment <number> --repo <owner>/<repo> --body "Your comment"
169
+
170
+ # Or via API
171
+ gh api -X POST /repos/<owner>/<repo>/issues/<number>/comments \
172
+ -f body="Your comment"
173
+ ```
174
+
175
+ ## Creating a Review
176
+
177
+ ### Create Review with Comments
178
+ ```bash
179
+ gh api -X POST /repos/<owner>/<repo>/pulls/<number>/reviews \
180
+ -f body="Overall review comments" \
181
+ -f event="COMMENT" \
182
+ -f commit_id="<sha>" \
183
+ -f comments='[{"path":"src/file.py","line":42,"body":"Comment on line 42"}]'
184
+ ```
185
+
186
+ ### Submit Review (Approve/Request Changes)
187
+ ```bash
188
+ # Approve
189
+ gh api -X POST /repos/<owner>/<repo>/pulls/<number>/reviews \
190
+ -f body="LGTM!" \
191
+ -f event="APPROVE" \
192
+ -f commit_id="<sha>"
193
+
194
+ # Request changes
195
+ gh api -X POST /repos/<owner>/<repo>/pulls/<number>/reviews \
196
+ -f body="Please address these issues" \
197
+ -f event="REQUEST_CHANGES" \
198
+ -f commit_id="<sha>"
199
+ ```
200
+
201
+ ## Searching and Filtering
202
+
203
+ ### Search Code in PR
204
+ ```bash
205
+ # Get PR diff and search
206
+ gh pr diff <number> --repo <owner>/<repo> | grep "search_term"
207
+
208
+ # Search in specific files
209
+ gh pr view <number> --repo <owner>/<repo> --json files --jq '.files[] | select(.path | contains("search_term"))'
210
+ ```
211
+
212
+ ### Filter by File Type
213
+ ```bash
214
+ gh pr view <number> --repo <owner>/<repo> --json files --jq '.files[] | select(.path | endswith(".py"))'
215
+ ```
216
+
217
+ ## Labels, Assignees, and Metadata
218
+
219
+ ### Get Labels
220
+ ```bash
221
+ gh pr view <number> --repo <owner>/<repo> --json labels --jq '.labels[].name'
222
+ ```
223
+
224
+ ### Get Assignees
225
+ ```bash
226
+ gh pr view <number> --repo <owner>/<repo> --json assignees --jq '.assignees[].login'
227
+ ```
228
+
229
+ ### Get Reviewers
230
+ ```bash
231
+ gh pr view <number> --repo <owner>/<repo> --json reviewRequests --jq '.reviewRequests[].login'
232
+ ```
233
+
234
+ ## Advanced Queries
235
+
236
+ ### Get PR Timeline
237
+ ```bash
238
+ gh api /repos/<owner>/<repo>/issues/<number>/timeline
239
+ ```
240
+
241
+ ### Get PR Events
242
+ ```bash
243
+ gh api /repos/<owner>/<repo>/issues/<number>/events
244
+ ```
245
+
246
+ ### Get All PR Data
247
+ ```bash
248
+ gh pr view <number> --repo <owner>/<repo> --json \
249
+ number,title,body,state,author,headRefName,baseRefName,\
250
+ commits,reviews,comments,files,labels,assignees,milestone,\
251
+ createdAt,updatedAt,mergedAt,closedAt,url,isDraft
252
+ ```
253
+
254
+ ## Common JQ Patterns
255
+
256
+ ### Extract specific fields
257
+ ```bash
258
+ --jq '.field'
259
+ --jq '.array[].field'
260
+ --jq '.[] | {field1, field2}'
261
+ ```
262
+
263
+ ### Filter arrays
264
+ ```bash
265
+ --jq '.[] | select(.field == "value")'
266
+ --jq '.[] | select(.field | contains("substring"))'
267
+ ```
268
+
269
+ ### Count items
270
+ ```bash
271
+ --jq '. | length'
272
+ --jq '.array | length'
273
+ ```
274
+
275
+ ### Map and transform
276
+ ```bash
277
+ --jq '.array | map(.field)'
278
+ --jq '.[] | {newField: .oldField}'
279
+ ```
280
+
281
+ ## Line Number Considerations for Inline Comments
282
+
283
+ **IMPORTANT**: The `line` parameter for inline comments refers to the **line number in the diff**, not the absolute line number in the file.
284
+
285
+ ### Understanding Diff Line Numbers
286
+
287
+ In a diff:
288
+ - Lines are numbered relative to the diff context, not the file
289
+ - The `side` parameter determines which version:
290
+ - `"RIGHT"`: New version (after changes)
291
+ - `"LEFT"`: Old version (before changes)
292
+
293
+ ### Finding Diff Line Numbers
294
+
295
+ ```bash
296
+ # Get diff with line numbers
297
+ gh pr diff <number> --repo <owner>/<repo> | cat -n
298
+
299
+ # Get specific file diff
300
+ gh api /repos/<owner>/<repo>/pulls/<number>/files --jq '.[] | select(.filename == "path/to/file")'
301
+ ```
302
+
303
+ ### Example Diff
304
+ ```diff
305
+ @@ -10,7 +10,8 @@ def process_data(data):
306
+ if not data:
307
+ return None
308
+
309
+ - result = old_function(data)
310
+ + # New implementation
311
+ + result = new_function(data)
312
+ return result
313
+ ```
314
+
315
+ In this diff:
316
+ - Line 13 (old) would be `side: "LEFT"`
317
+ - Line 14-15 (new) would be `side: "RIGHT"`
318
+ - Line numbers are relative to the diff hunk starting at line 10
319
+
320
+ ## Error Handling
321
+
322
+ ### Common Errors
323
+
324
+ **Resource not found**:
325
+ ```bash
326
+ # Check repo access
327
+ gh repo view <owner>/<repo>
328
+
329
+ # Check PR exists
330
+ gh pr list --repo <owner>/<repo> | grep <number>
331
+ ```
332
+
333
+ **API rate limit**:
334
+ ```bash
335
+ # Check rate limit
336
+ gh api /rate_limit
337
+
338
+ # Use authentication to get higher limits
339
+ gh auth login
340
+ ```
341
+
342
+ **Permission denied**:
343
+ ```bash
344
+ # Check authentication
345
+ gh auth status
346
+
347
+ # May need additional scopes
348
+ gh auth refresh -s repo
349
+ ```
350
+
351
+ ## Tips and Best Practices
352
+
353
+ 1. **Use `--paginate`** for large result sets (comments, commits)
354
+ 2. **Combine with `jq`** for powerful filtering and formatting
355
+ 3. **Cache results** by saving to files to avoid repeated API calls
356
+ 4. **Check rate limits** when making many API calls
357
+ 5. **Use `--json` output** for programmatic parsing
358
+ 6. **Specify `--repo`** when outside repository directory
359
+ 7. **Get latest commit** before adding inline comments
360
+ 8. **Test comments** on draft PRs or test repositories first
361
+
362
+ ## Reference Links
363
+
364
+ - GitHub CLI Manual: https://cli.github.com/manual/
365
+ - GitHub REST API: https://docs.github.com/en/rest
366
+ - JQ Manual: https://jqlang.github.io/jq/manual/
367
+ - PR Review Comments API: https://docs.github.com/en/rest/pulls/comments
368
+ - PR Reviews API: https://docs.github.com/en/rest/pulls/reviews
@@ -0,0 +1,345 @@
1
+ # Code Review Criteria
2
+
3
+ This document outlines the comprehensive criteria for conducting pull request code reviews. Use this as a checklist when reviewing PRs to ensure thorough, consistent, and constructive feedback.
4
+
5
+ ## Review Process Overview
6
+
7
+ When reviewing a PR, the goal is to ensure changes are:
8
+ - **Correct**: Solves the intended problem without bugs
9
+ - **Maintainable**: Easy to understand and modify
10
+ - **Aligned**: Follows project standards and conventions
11
+ - **Secure**: Free from vulnerabilities
12
+ - **Tested**: Covered by appropriate tests
13
+
14
+ ## 1. Functionality and Correctness
15
+
16
+ ### Problem Resolution
17
+ - [ ] **Does the code solve the intended problem?**
18
+ - Verify changes address the issue or feature described in the PR
19
+ - Cross-reference with linked tickets (JIRA, GitHub issues)
20
+ - Test manually or run the code if possible
21
+
22
+ ### Bugs and Logic
23
+ - [ ] **Are there bugs or logical errors?**
24
+ - Check for off-by-one errors
25
+ - Verify null/undefined/None handling
26
+ - Review assumptions about inputs and outputs
27
+ - Look for race conditions or concurrency issues
28
+ - Check loop termination conditions
29
+
30
+ ### Edge Cases and Error Handling
31
+ - [ ] **Edge cases handled?**
32
+ - Empty collections (arrays, lists, maps)
33
+ - Null/None/undefined values
34
+ - Boundary values (min/max integers, empty strings)
35
+ - Invalid or malformed inputs
36
+
37
+ - [ ] **Error handling implemented?**
38
+ - Network failures
39
+ - File system errors
40
+ - Database connection issues
41
+ - API errors and timeouts
42
+ - Graceful degradation
43
+
44
+ ### Compatibility
45
+ - [ ] **Works across supported environments?**
46
+ - Browser compatibility (if web app)
47
+ - OS versions (if desktop/mobile)
48
+ - Database versions
49
+ - Language/runtime versions
50
+ - Doesn't break existing features (regression check)
51
+
52
+ ## 2. Readability and Maintainability
53
+
54
+ ### Code Clarity
55
+ - [ ] **Easy to read and understand?**
56
+ - Meaningful variable names (avoid `x`, `temp`, `data`)
57
+ - Meaningful function names (verb-first, descriptive)
58
+ - Short methods/functions (ideally < 50 lines)
59
+ - Logical structure and flow
60
+ - Minimal nested complexity
61
+
62
+ ### Modularity
63
+ - [ ] **Single Responsibility Principle?**
64
+ - Functions/methods do one thing well
65
+ - Classes have a clear, focused purpose
66
+ - No "god objects" or overly complex logic
67
+
68
+ - [ ] **Suggest refactoring if needed:**
69
+ - Extract complex logic into helper functions
70
+ - Break large functions into smaller ones
71
+ - Separate concerns (UI, business logic, data access)
72
+
73
+ ### Code Duplication
74
+ - [ ] **DRY (Don't Repeat Yourself)?**
75
+ - Repeated code abstracted into helpers
76
+ - Shared logic moved to libraries/utilities
77
+ - Avoid copy-paste programming
78
+
79
+ ### Future-Proofing
80
+ - [ ] **Allows for easy extensions?**
81
+ - Avoid hard-coded values (use constants/configs)
82
+ - Use dependency injection where appropriate
83
+ - Follow SOLID principles
84
+ - Consider extensibility without modification
85
+
86
+ ## 3. Style and Conventions
87
+
88
+ ### Style Guide Adherence
89
+ - [ ] **Follows project linter rules?**
90
+ - ESLint (JavaScript/TypeScript)
91
+ - Pylint/Flake8/Black (Python)
92
+ - RuboCop (Ruby)
93
+ - Checkstyle/PMD (Java)
94
+ - golangci-lint (Go)
95
+
96
+ - [ ] **Formatting consistent?**
97
+ - Proper indentation (spaces vs. tabs)
98
+ - Consistent spacing
99
+ - Line length limits
100
+ - Import/require organization
101
+
102
+ ### Codebase Consistency
103
+ - [ ] **Matches existing patterns?**
104
+ - Follows established architectural patterns
105
+ - Uses existing utilities and helpers
106
+ - Consistent naming conventions
107
+ - Matches idioms of the language/framework
108
+
109
+ ### Comments and Documentation
110
+ - [ ] **Sufficient comments?**
111
+ - Complex algorithms explained
112
+ - Non-obvious decisions documented
113
+ - API contracts clarified
114
+ - TODOs tracked with ticket numbers
115
+
116
+ - [ ] **Not excessive?**
117
+ - Code should be self-documenting where possible
118
+ - Avoid obvious comments ("increment i")
119
+
120
+ - [ ] **Documentation updated?**
121
+ - README reflects new features
122
+ - API docs updated
123
+ - Inline docs (JSDoc, docstrings, etc.)
124
+ - Architecture diagrams current
125
+
126
+ ## 4. Performance and Efficiency
127
+
128
+ ### Resource Usage
129
+ - [ ] **Algorithm efficiency?**
130
+ - Avoid O(n²) or worse in loops
131
+ - Use appropriate data structures
132
+ - Minimize database queries (N+1 problem)
133
+ - Avoid unnecessary computations
134
+
135
+ ### Scalability
136
+ - [ ] **Performs well under load?**
137
+ - No blocking operations in critical paths
138
+ - Async/await for I/O operations
139
+ - Pagination for large datasets
140
+ - Caching where appropriate
141
+
142
+ ### Optimization Balance
143
+ - [ ] **Optimizations necessary?**
144
+ - Premature optimization avoided
145
+ - Readability not sacrificed for micro-optimizations
146
+ - Benchmark before complex optimizations
147
+ - Profile to identify actual bottlenecks
148
+
149
+ ## 5. Security and Best Practices
150
+
151
+ ### Vulnerabilities
152
+ - [ ] **Common security issues addressed?**
153
+ - SQL injection (use parameterized queries)
154
+ - XSS (Cross-Site Scripting) - proper escaping
155
+ - CSRF (Cross-Site Request Forgery) - tokens
156
+ - Command injection
157
+ - Path traversal
158
+ - Authentication/authorization checks
159
+
160
+ ### Data Handling
161
+ - [ ] **Sensitive data protected?**
162
+ - Encrypted in transit (HTTPS/TLS)
163
+ - Encrypted at rest
164
+ - Input validation and sanitization
165
+ - Output encoding
166
+ - PII handling compliance (GDPR, etc.)
167
+
168
+ - [ ] **Secrets management?**
169
+ - No hardcoded passwords/API keys
170
+ - Use environment variables
171
+ - Use secret management systems
172
+ - No secrets in logs
173
+
174
+ ### Dependencies
175
+ - [ ] **New packages justified?**
176
+ - Actually necessary
177
+ - From trusted sources
178
+ - Up-to-date and maintained
179
+ - No known vulnerabilities
180
+ - License compatible
181
+
182
+ - [ ] **Dependency management?**
183
+ - Lock files committed
184
+ - Minimal dependency footprint
185
+ - Consider alternatives if bloated
186
+
187
+ ## 6. Testing and Quality Assurance
188
+
189
+ ### Test Coverage
190
+ - [ ] **Tests exist for new code?**
191
+ - Unit tests for individual functions/methods
192
+ - Integration tests for workflows
193
+ - End-to-end tests for critical paths
194
+
195
+ - [ ] **Tests cover scenarios?**
196
+ - Happy paths
197
+ - Error conditions
198
+ - Edge cases
199
+ - Boundary conditions
200
+
201
+ ### Test Quality
202
+ - [ ] **Tests are meaningful?**
203
+ - Not just for coverage metrics
204
+ - Assert actual behavior
205
+ - Test intent, not implementation
206
+ - Avoid brittle tests
207
+
208
+ - [ ] **Test maintainability?**
209
+ - Clear test names
210
+ - Arrange-Act-Assert pattern
211
+ - Minimal test duplication
212
+ - Fast execution
213
+
214
+ ### CI/CD Integration
215
+ - [ ] **Automated checks pass?**
216
+ - Linting
217
+ - Tests (unit, integration, e2e)
218
+ - Build process
219
+ - Security scans
220
+ - Code coverage thresholds
221
+
222
+ ## 7. Overall PR Quality
223
+
224
+ ### Scope
225
+ - [ ] **PR is focused?**
226
+ - Single feature/fix per PR
227
+ - Not too large (< 400 lines ideal)
228
+ - Suggest splitting if combines unrelated changes
229
+
230
+ ### Commit History
231
+ - [ ] **Clean, atomic commits?**
232
+ - Each commit is logical unit
233
+ - Descriptive commit messages
234
+ - Follow conventional commits if applicable
235
+ - Avoid "fix", "update", "wip" vagueness
236
+
237
+ ### PR Description
238
+ - [ ] **Clear description?**
239
+ - Explains **why** changes were made
240
+ - Links to tickets/issues
241
+ - Steps to reproduce/test
242
+ - Screenshots for UI changes
243
+ - Breaking changes called out
244
+ - Migration steps if needed
245
+
246
+ ### Impact Assessment
247
+ - [ ] **Considered downstream effects?**
248
+ - API changes (breaking vs. backward-compatible)
249
+ - Database schema changes
250
+ - Impact on other teams/services
251
+ - Performance implications
252
+ - Monitoring and alerting needs
253
+
254
+ ## Review Feedback Guidelines
255
+
256
+ ### Communication Style
257
+ - **Be constructive and kind**
258
+ - Frame as suggestions: "Consider X because Y"
259
+ - Not criticism: "This is wrong"
260
+ - Acknowledge good work
261
+ - Explain the "why" behind feedback
262
+
263
+ ### Prioritization
264
+ - **Focus on critical issues first:**
265
+ 1. Bugs and correctness
266
+ 2. Security vulnerabilities
267
+ 3. Performance problems
268
+ 4. Design/architecture issues
269
+ 5. Style and conventions
270
+
271
+ ### Feedback Markers
272
+ Use clear markers to indicate severity:
273
+ - **🔴 Blocker**: Must be fixed before merge
274
+ - **🟡 Important**: Should be addressed
275
+ - **🟢 Nit**: Nice to have, optional
276
+ - **💡 Suggestion**: Consider for future
277
+ - **❓ Question**: Clarification needed
278
+ - **✅ Praise**: Good work!
279
+
280
+ ### Time Efficiency
281
+ - Review promptly (within 24 hours)
282
+ - For large PRs, review in chunks
283
+ - Request smaller PRs if too large
284
+ - Use automated tools to catch style issues
285
+
286
+ ### Decision Making
287
+ - **Approve**: Solid overall, minor nits acceptable
288
+ - **Request Changes**: Blockers must be addressed
289
+ - **Comment**: Provide feedback without blocking
290
+
291
+ ## Language/Framework-Specific Considerations
292
+
293
+ ### JavaScript/TypeScript
294
+ - Type safety (TypeScript)
295
+ - Promise handling (avoid callback hell)
296
+ - Memory leaks (event listeners)
297
+ - Bundle size impact
298
+
299
+ ### Python
300
+ - PEP 8 compliance
301
+ - Type hints (Python 3.5+)
302
+ - Virtual environment dependencies
303
+ - Generator usage for memory efficiency
304
+
305
+ ### Java
306
+ - Memory management
307
+ - Exception handling (checked vs. unchecked)
308
+ - Thread safety
309
+ - Immutability where appropriate
310
+
311
+ ### Go
312
+ - Error handling (no exceptions)
313
+ - Goroutine management
314
+ - Channel usage
315
+ - Interface design
316
+
317
+ ### SQL/Database
318
+ - Index usage
319
+ - Query performance
320
+ - Transaction boundaries
321
+ - Migration reversibility
322
+
323
+ ### Frontend (React, Vue, Angular)
324
+ - Component reusability
325
+ - State management
326
+ - Accessibility (a11y)
327
+ - Performance (re-renders, bundle size)
328
+
329
+ ## Tools and Automation
330
+
331
+ Leverage tools to automate checks:
332
+ - **Linters**: ESLint, Pylint, RuboCop
333
+ - **Formatters**: Prettier, Black, gofmt
334
+ - **Security**: Snyk, CodeQL, Dependabot
335
+ - **Coverage**: Codecov, Coveralls
336
+ - **Performance**: Lighthouse, WebPageTest
337
+ - **Accessibility**: axe, WAVE
338
+
339
+ ## Resources
340
+
341
+ - Google Engineering Practices: https://google.github.io/eng-practices/review/
342
+ - GitHub Code Review Guide: https://github.com/features/code-review
343
+ - OWASP Top 10: https://owasp.org/www-project-top-ten/
344
+ - Clean Code (Robert C. Martin)
345
+ - Code Complete (Steve McConnell)