You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Review the current branch against `develop` and report only material issues with high signal: bugs, regressions, API breaks, resource/concurrency risks, and behavior changes.
5
+
6
+
## When to Use
7
+
- Before opening a pull request to `develop`
8
+
- After major refactoring or API changes
9
+
- When you want a strict, impact-focused review
10
+
11
+
## Review Scope (RLib-specific)
12
+
1.**Public API compatibility first**
13
+
- Treat removals/signature changes in public API as high priority by default
14
+
- If branch is intentionally alpha-breaking, mark these as accepted and continue
15
+
16
+
2.**Prioritize API surface over internals**
17
+
- Start with changed files in `src/main/java`
18
+
- Prioritize non-`impl/` packages
19
+
- Review `impl/` changes when they can affect exposed behavior
20
+
21
+
3.**Javadoc quality is part of API review**
22
+
- Check public API javadocs for:
23
+
-`@since 10.0.0`
24
+
- Active voice descriptions
25
+
- No trailing periods in `@param`/`@return`
26
+
- No unnecessary getter/setter javadocs
27
+
28
+
4.**Collections performance pattern**
29
+
- Verify empty-state fast paths (`isEmpty()`) in collection operations
30
+
- Ensure no unnecessary allocation/iteration when collections are empty
31
+
32
+
5.**Runtime/integration constraints**
33
+
- Many integration tests use Testcontainers
34
+
- If Docker is unavailable, call out that integration validation is limited
35
+
36
+
6.**Testing conventions awareness**
37
+
- Prefer AssertJ assertions
38
+
- Keep test naming and style aligned with repo conventions
39
+
40
+
7.**Version mapping correctness**
41
+
- For version-to-name lookups (for example OS distribution naming), verify runtime version normalization before map access
42
+
- Confirm behavior for real version formats (for example `10.15.7`, `14.4.1`, `15.1`) with targeted tests
Copy file name to clipboardExpand all lines: .github/skills/generate-javadoc.md
+6-3Lines changed: 6 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -37,6 +37,7 @@ When the user asks to:
37
37
2.**Function @return** - use "the function result" for consistency
38
38
3.**Predicate @return** - use "true if the arguments match the predicate" or "true if the arguments match the predicate, false otherwise"
39
39
4.**Supplier @return** - describe what is supplied (e.g., "the char value" not just "a result")
40
+
5.**Signature-text alignment** - ensure class-level description and type-parameter text match the exact argument order in `make(...)`/`accept(...)` methods (for example, `A, int, C` must be described as "an object, an int, and another object", while `A, B, int` must be described as "two objects and one int")
40
41
41
42
### Javadoc Standards
42
43
Each documented element must include:
@@ -129,6 +130,7 @@ public interface IntObjConsumer<B> {
0 commit comments