@groupby/ai-dev 0.5.11 → 0.5.12
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/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: team-code-review
|
|
3
3
|
description: >-
|
|
4
|
-
Review current changes against the repository's AI routing docs, working agreement, architecture, code-review checklist, and changed files. Use for phase reviews, final branch reviews, PR readiness checks, or focused reviews where findings should be prioritized before summary.
|
|
4
|
+
Review current changes against the repository's AI routing docs, working agreement, architecture, code-review checklist, and changed files. Scores the change across review axes (correctness, readability, architecture, security, performance) and tags each finding with a severity label so blockers are obvious. Use for phase reviews, final branch reviews, PR readiness checks, or focused reviews where findings should be prioritized before summary.
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Team Code Review
|
|
@@ -28,39 +28,59 @@ Use this skill for read-first review work. The project docs define the review st
|
|
|
28
28
|
- architecture or task-specific docs named by the router
|
|
29
29
|
4. Inspect changed files and nearby code before writing findings.
|
|
30
30
|
|
|
31
|
-
## Review
|
|
31
|
+
## Review Axes
|
|
32
32
|
|
|
33
|
-
|
|
33
|
+
Review the change across these axes and score each one. Scoring forces a deliberate pass over every axis instead of stopping at the first issue found.
|
|
34
34
|
|
|
35
|
-
-
|
|
36
|
-
-
|
|
37
|
-
-
|
|
38
|
-
-
|
|
39
|
-
-
|
|
40
|
-
- accessibility for UI work
|
|
41
|
-
- test coverage and validation gaps
|
|
42
|
-
- docs drift caused by the change
|
|
35
|
+
- **Correctness** — user-visible behavior, edge cases, error handling and failure states, test coverage and validation gaps.
|
|
36
|
+
- **Readability** — clarity, naming, and complexity. Could another engineer follow this without explanation?
|
|
37
|
+
- **Architecture** — documented conventions, module boundaries, and docs drift caused by the change.
|
|
38
|
+
- **Security** — input validation, permissions, auth, and sensitive data handling.
|
|
39
|
+
- **Performance** — inefficient or expensive code, and lifecycle cleanup.
|
|
43
40
|
|
|
44
|
-
|
|
41
|
+
For UI work, also review accessibility (semantic markup, keyboard navigation, focus management) under Readability and Correctness.
|
|
42
|
+
|
|
43
|
+
Prioritize defects and regressions over style. If the code contradicts project docs, treat that as a finding unless the change deliberately updates the documented target state.
|
|
44
|
+
|
|
45
|
+
## Severity Labels
|
|
46
|
+
|
|
47
|
+
Tag every finding so the reader instantly knows what blocks merge versus what is optional:
|
|
48
|
+
|
|
49
|
+
| Label | Meaning |
|
|
50
|
+
|---|---|
|
|
51
|
+
| `Critical:` | Blocks merge — security hole, data loss, broken or wrong behavior. |
|
|
52
|
+
| `Required:` | Must change before merge, but not merge-breaking on its own. |
|
|
53
|
+
| `Consider:` | Worth evaluating. A suggestion, not a blocker. |
|
|
54
|
+
| `Nit:` | Optional minor or style feedback. |
|
|
55
|
+
| `FYI:` | Informational only, no action needed. |
|
|
45
56
|
|
|
46
57
|
## Output
|
|
47
58
|
|
|
48
|
-
|
|
59
|
+
Group findings by axis, and prefix each with its severity label. Include tight file and line references when possible. Lead with the axes that have the most severe findings.
|
|
49
60
|
|
|
50
61
|
Use this shape:
|
|
51
62
|
|
|
52
63
|
```markdown
|
|
53
64
|
## Findings
|
|
54
|
-
|
|
65
|
+
|
|
66
|
+
### Correctness
|
|
67
|
+
- Critical: file:line - Issue and impact.
|
|
68
|
+
- Consider: file:line - Issue and impact.
|
|
69
|
+
|
|
70
|
+
### Security
|
|
71
|
+
- Critical: file:line - Issue and impact.
|
|
72
|
+
|
|
73
|
+
### Readability
|
|
74
|
+
- Nit: file:line - Issue and impact.
|
|
55
75
|
|
|
56
76
|
## Open Questions
|
|
57
77
|
- [Question]
|
|
58
78
|
|
|
59
79
|
## Summary
|
|
60
|
-
[Brief assessment]
|
|
80
|
+
[Brief assessment, with a per-axis read and the total count by severity, e.g. "2 critical, 1 consider, 1 nit. Blocks merge until criticals are fixed."]
|
|
61
81
|
|
|
62
82
|
## Validation Gaps
|
|
63
83
|
- [Gap]
|
|
64
84
|
```
|
|
65
85
|
|
|
66
|
-
If the project workflow requires a review artifact, write it to the documented scratch location, commonly `tmp/review-phase-XX.md` or `tmp/review-final.md`.
|
|
86
|
+
Only include axes that have findings. If the project workflow requires a review artifact, write it to the documented scratch location, commonly `tmp/review-phase-XX.md` or `tmp/review-final.md`.
|