Improved skills

Author: AlexeyKuznetsov-DD

.claude/skills/migrate-groovy-to-java/SKILL.md

@@ -16,8 +16,11 @@ Migrate test Groovy files to Java using JUnit 5
 
 When converting Groovy code to Java code, make sure that:
 - The Java code generated is compatible with JDK 8
-- When translating Spock tests, favor using @TableTest. See detailed instructions in the "TableTest Usage" section of this document.
-- When usage of `@TableTest` impossible, use `@MethodSource`, and name the arguments method by appending `Arguments` using camelCase to the test method name (e.g. `testMethodArguments`) and return a `Stream` of arguments using `Stream.of(...)` and `arguments(...)` with static import.
+- When translating Spock tests, prefer `@TableTest` for data rows that are naturally tabular. See detailed guidance in the "TableTest usage" section.
+- `@TableTest` and `@MethodSource` may be combined on the same `@ParameterizedTest` when most cases are tabular but a few cases require programmatic setup.
+- In combined mode, keep table-friendly cases in `@TableTest`, and put only non-tabular/complex cases in `@MethodSource`.
+- If `@TableTest` is not viable for the test at all, use `@MethodSource` only.
+- For `@MethodSource`, name the arguments method `<testMethodName>Arguments` (camelCase, e.g. `testMethodArguments`) and return `Stream<Arguments>` using `Stream.of(...)` and `arguments(...)` with static import.
 - Ensure parameterized test names are human-readable (i.e. no hashcodes); instead add a description string as the first `Arguments.arguments(...)` value or index the test case
 - When converting tuples, create a light dedicated structure instead to keep the typing system
 - Instead of checking a state and throwing an exception, use JUnit asserts
@@ -48,7 +51,8 @@ TableTest usage
     - Collections: `[a, b]` = List/array, `{a, b}` = Set, `[k: v]` = Map.
 
   Mixed eligibility:
-    - Simple rows ⇒ @TableTest; complex rows (mocks, builders) ⇒ separate `@Test`(s) or small `@MethodSource`.
+    - Prefer combining `@TableTest` + `@MethodSource` on one `@ParameterizedTest` when only some cases are complex.
+    - Use `@MethodSource`-only only when tabular representation is not practical for the test.
 
   Do NOT use @TableTest when:
     - Majority of rows require complex objects or custom converters.

.claude/skills/use-tabletest/SKILL.md

@@ -48,6 +48,10 @@ C) @MethodSource (convert only if values are representable as strings)
   - List: [a, b, ...]
   - Set: {a, b, ...}
   - Map: [k: v, ...]
+- `@TableTest` and `@MethodSource` may be combined on the same `@ParameterizedTest` when most cases are tabular but a few cases require programmatic setup.
+- In combined mode, keep table-friendly cases in `@TableTest`, and put only non-tabular/complex cases in `@MethodSource`.
+- If `@TableTest` is not viable for the test at all, use `@MethodSource` only.
+- For `@MethodSource`, name the arguments method `<testMethodName>Arguments` (camelCase, e.g. `testMethodArguments`) and return `Stream<Arguments>` using `Stream.of(...)` and `arguments(...)` with static import.
 - Blank cell = null (non-primitive).
 - '' = empty string.
 - For String params that start with '[' or '{', quote to avoid collection parsing (prefer '[]'/'{}').
@@ -59,9 +63,8 @@ Cleanup:
 - Delete now-unused @MethodSource provider methods and unused imports.
 
 Mixed eligibility:
-- If only a few cases need complex construction, split:
-  - Simple cases ⇒ @TableTest
-  - Complex cases ⇒ separate @Test(s) (descriptive names) OR keep a small @MethodSource.
+- Prefer combining `@TableTest` + `@MethodSource` on one `@ParameterizedTest` when only some cases are complex.
+- Use `@MethodSource`-only only when tabular representation is not practical for the test.
 
 Do NOT convert when:
 - Most rows require complex builders/mocks.