@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.
- package/README.md +53 -0
- package/bin/install.mjs +104 -0
- package/lib/manifest.d.ts +33 -0
- package/lib/manifest.mjs +102 -0
- package/manifest.json +52 -0
- package/package.json +47 -0
- package/skills/check-mcp/SKILL.md +40 -0
- package/skills/deployment-completeness-audit/SKILL.md +255 -0
- package/skills/papi-advanced/SKILL.md +28 -0
- package/skills/papi-build/SKILL.md +52 -0
- package/skills/papi-idea/SKILL.md +37 -0
- package/skills/papi-plan/SKILL.md +164 -0
- package/skills/papi-strategy/SKILL.md +28 -0
- package/skills/playwright-skill/API_REFERENCE.md +653 -0
- package/skills/playwright-skill/EXAMPLES.md +166 -0
- package/skills/playwright-skill/SKILL.md +147 -0
- package/skills/playwright-skill/lib/helpers.js +441 -0
- package/skills/playwright-skill/package.json +26 -0
- package/skills/playwright-skill/run.js +228 -0
- package/skills/pr-reviewer/SKILL.md +443 -0
- package/skills/pr-reviewer/references/gh_cli_guide.md +368 -0
- package/skills/pr-reviewer/references/review_criteria.md +345 -0
- package/skills/pr-reviewer/references/scenarios.md +71 -0
- package/skills/pr-reviewer/references/troubleshooting.md +55 -0
- package/skills/pr-reviewer/scripts/add_inline_comment.py +163 -0
- package/skills/pr-reviewer/scripts/fetch_pr_data.py +327 -0
- package/skills/pr-reviewer/scripts/generate_review_files.py +480 -0
|
@@ -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)
|