@mrciphersmith/keryx 0.3.3 → 0.3.6

package/src/gdskills/bundled/stacks/java-kotlin-spring/skills/java-kotlin-spring-migrate/evals.json

@@ -0,0 +1,74 @@
+{
+  "triggers": {
+    "positive": [
+      "We're adding an order_status column to the orders table -- what does a properly versioned Flyway script for that look like?",
+      "Write a Liquibase changeset to add an index on the orders table",
+      "Before this runs against the shared staging database, can you check whether my new V12 migration script is safe?",
+      "I need to rename the customer_email column without breaking rows that are mid-deploy -- what's the safe multi-step Flyway approach for that?",
+      "Flyway is refusing to start up because it says the checksum on V7 doesn't match what's recorded in the history table -- how do I resolve that safely?",
+      "We're dropping a legacy is_archived flag from the schema -- what should the migration script for that look like?",
+      "Write a Flyway migration that backfills a new not-null column"
+    ],
+    "negative": [
+      "Write a Django migration for this new model field",
+      "Add a Rails ActiveRecord migration for this column",
+      "Implement a new Spring service method that reads from this table",
+      "Review this Spring controller for entity leakage",
+      "Fix this failing Gradle build for the Spring project",
+      "Write JUnit tests for this Spring repository"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "never-edit-applied-migration",
+      "prompt": "I found a typo in a column name inside V7__add_users_table.sql, which has already been applied in staging. Should I just fix the typo in that file?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer refuses to edit V7__add_users_table.sql directly because it has already been applied, explaining that changing an applied migration's content changes its checksum and will fail validation in any environment that already ran it. It directs adding a new migration (e.g. a rename statement) instead.",
+          "pass_criteria": [
+            "States explicitly that V7__add_users_table.sql must not be edited because it has already been applied in staging.",
+            "Explains the concrete consequence: editing it changes its checksum, which will fail Flyway/Liquibase validation in staging (or anywhere else it already ran).",
+            "Directs creating a new migration (e.g. a rename/correction statement in a new versioned file) as the fix instead."
+          ],
+          "fail_criteria": [
+            "Recommends editing V7__add_users_table.sql directly to fix the typo, with no new migration created."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "No -- don't edit V7__add_users_table.sql. Flyway records a checksum for every migration it has applied, and once V7 has run in staging, changing its file content (even a one-character typo fix) changes that checksum. The next time Flyway validates against staging, it'll detect the mismatch and fail -- staging has a different version of V7 recorded than what's now on disk. Instead, add a new migration (say V13__rename_users_typo_column.sql) that does the correction with an ALTER TABLE ... RENAME COLUMN statement. That way every environment, no matter which point it's already migrated to, gets the fix applied cleanly as a new step rather than needing V7 itself to change underneath it.",
+        "known_wrong": "Since it's just a typo and hasn't gone to production yet, I'd just fix it directly in V7__add_users_table.sql -- staging can just re-run the migration or you can manually correct the column name there once. It's a one-character change, adding a whole new migration file for something this small feels like overkill.",
+        "vague": "You probably shouldn't touch a migration that's already been applied -- handle the typo the right way instead.",
+        "subtle_wrong": "Since it's only in staging and not production yet, you can edit V7__add_users_table.sql directly and then just re-apply Flyway's `repair` command in staging to reset the checksum before running the corrected migration again -- that gets the file itself clean without needing an extra V13 migration cluttering up the history for what's really just a typo fix."
+      },
+      "anti_patterns": ["v7__add_users_table.sql"]
+    },
+    {
+      "id": "verify-before-reporting-done",
+      "prompt": "I wrote a new Flyway migration that adds a NOT NULL column with a default value to the orders table. It looks correct to me -- is writing the SQL enough, or do I need to do anything else before considering this done?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer states that the migration must actually be run against a real database with a real migration command (flywayMigrate, with flywayValidate, or the project's equivalent) before being considered done -- reading the SQL and judging it correct by eye is not sufficient, since a migration can fail on the real database (constraint conflicts, backfill issues) even when the SQL looks right.",
+          "pass_criteria": [
+            "States that reading/reviewing the SQL is not sufficient on its own -- the migration must actually be executed with a real migration command.",
+            "Names a concrete command (flywayMigrate/flywayValidate, or the project's Liquibase equivalent) to run against a local/test database.",
+            "Gives a concrete reason verification matters here specifically -- e.g. a NOT NULL column addition can fail against existing rows with no default applied correctly, or a constraint conflict only surfaces at execution time."
+          ],
+          "fail_criteria": [
+            "States or implies that reading the SQL and confirming it looks correct is sufficient, with no actual migration command needing to be run before considering the work done."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Reading the SQL isn't enough here -- run it. Execute `flywayMigrate` (or your build tool's equivalent, e.g. `./gradlew flywayMigrate`) against a local or test database that has representative existing data, then `flywayValidate` to confirm the applied state matches what's on disk. This matters especially for a NOT NULL column with a default: the syntax can look completely correct while still failing against existing rows if the default isn't actually being applied the way you expect on this database engine, or if there's a constraint you didn't account for. Only after it actually runs cleanly against a real database should you consider this done -- never claim a migration is correct purely from reading the SQL.",
+        "known_wrong": "If the SQL syntax looks right and follows the same pattern as your other migrations, that's good enough -- you don't need to actually run it locally first, since ADD COLUMN ... NOT NULL DEFAULT ... is a pretty standard, low-risk statement. Just commit it and let it apply automatically when the app starts up in the next environment; if something's actually wrong you'll find out then.",
+        "vague": "Make sure the migration actually works before you call it done, not just that it reads fine.",
+        "subtle_wrong": "The SQL pattern here is common enough (ADD COLUMN with NOT NULL and a DEFAULT) that as long as it matches how earlier migrations in this project added similar columns, you can be confident it'll apply cleanly -- I'd skip a separate local run for something this standard and just let flywayMigrate pick it up the first time the app boots against the target database, same as any other migration."
+      }
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/java-kotlin-spring/skills/java-kotlin-spring-testing/SKILL.md

@@ -0,0 +1,128 @@
+---
+name: java-kotlin-spring-testing
+description: "Use when a Java or Kotlin Spring Boot test suite needs writing, extending, or fixing -- JUnit 5, Mockito/MockK, the narrowest Spring test slice (@WebMvcTest/@DataJpaTest/@SpringBootTest), MockMvc, Awaitility instead of Thread.sleep, and Testcontainers for repository tests."
+triggers:
+  - "write JUnit tests for this Spring service"
+  - "add MockMvc tests for this Spring controller"
+  - "write a @DataJpaTest for this repository"
+  - "fix this failing Spring Boot test"
+  - "add Mockito tests for this Java class"
+  - "write MockK tests for this Kotlin Spring service"
+  - "add a Testcontainers integration test for this repository"
+metadata:
+  origin: authored
+  category: test
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Java/Kotlin + Spring testing (JUnit 5 + Spring Boot Test)
+
+Write, extend, or fix a Java or Kotlin Spring Boot test suite: JUnit 5,
+Mockito/MockK, the narrowest applicable Spring test slice, MockMvc,
+Awaitility, and Testcontainers. `rules/testing.mdc` carries the full rule
+set this skill's checklist is built from — read it, not just this
+summary, before writing tests.
+
+## Workflow
+
+### Step 1: Discover the project's test conventions
+
+1. Read `pom.xml`/`build.gradle(.kts)` to confirm the test dependencies
+   already present: JUnit 5, Mockito or MockK, AssertJ, Testcontainers,
+   Awaitility.
+2. Find the layout: `src/test/java` or `src/test/kotlin`, mirroring the
+   main package, named `<Type>Test`/`<Type>IT`. Match whichever the
+   project already uses.
+3. Read 1-2 neighboring test classes for: assertion style already in
+   use, whether `@SpringBootTest` or a narrower slice
+   (`@WebMvcTest`/`@DataJpaTest`) is the norm, and existing
+   fixture/builder helpers for entities and DTOs.
+
+### Step 2: Plan test cases and pick the right slice
+
+**Plain unit test (no Spring container):** for a service's business
+logic with mocked collaborators — the default choice when the class was
+designed with constructor injection, since it can be constructed
+directly with `Mockito.mock(...)`/MockK mocks passed to the constructor.
+
+**`@WebMvcTest`:** for a controller — loads only the web layer, use
+`MockMvc` to exercise request/response mapping, status codes, and
+validation errors, with the service layer mocked via `@MockitoBean`
+(Spring Boot's own `@MockBean` is deprecated as of Boot 3.4 and removed
+in 4.x -- use `@MockitoBean` unless the project is pinned below 3.4).
+
+**`@DataJpaTest`:** for a repository — loads only the JPA slice against
+an embedded/test database, verifies query methods (including
+`@EntityGraph`/`JOIN FETCH` actually avoid N+1 where that matters).
+
+**`@SpringBootTest`:** only when the interaction across the whole wired
+context is genuinely what is under test — it is the slowest option and
+not a substitute for testing a service in isolation.
+
+Cover: happy path, validation-failure cases (Bean Validation constraint
+violations), the self-invocation `@Transactional` boundary if the change
+touches one, and any N+1-prone query path.
+
+### Step 3: Write
+
+1. Create/extend the test file at the project's own convention path.
+2. Construct the class under test directly when possible (Mockito
+   `@Mock`/`@InjectMocks` or manual construction with mocks passed to the
+   constructor); reach for `@MockitoBean` only inside a Spring test slice
+   (`@MockBean` only on a project still pinned below Spring Boot 3.4).
+3. For a controller test, assert status code, response body shape, and
+   that a Bean Validation failure returns the expected 400 response.
+4. For a repository test needing a real database, use Testcontainers
+   when the project already has it wired up, rather than substituting an
+   in-memory database that may not reject what production would.
+5. Never wait for an async result with `Thread.sleep`/`delay` — use
+   Awaitility's `await().atMost(...).until(...)`, a `CompletableFuture`
+   join, or a `CountDownLatch`.
+
+### Step 4: Run and fix
+
+```bash
+./gradlew test      # or: mvn test
+```
+
+Fix failing tests (max 3 iterations) — fix the test, not the source under
+test, unless the test itself has correctly caught a real bug (say so in
+the report rather than silently changing production code).
+
+### Step 5: Report
+
+```
+Generated: OrderServiceTest, OrderControllerTest (MockMvc), OrderRepositoryTest (@DataJpaTest)
+  - 9 test cases, all passing under ./gradlew test
+```
+
+## Rules
+
+- ALWAYS match the project's existing test-slice, mocking, and assertion
+  conventions found in Step 1, not a different project's style.
+- NEVER modify source code — only test files.
+- NEVER use `Thread.sleep`/`delay` to wait for an async result.
+- ALWAYS choose the narrowest Spring test slice that covers what is being
+  tested, not `@SpringBootTest` by default.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll add `Thread.sleep(500)` so the async call finishes before I assert" | Non-deterministic under load; use Awaitility or a real join/latch so the test cannot flake |
+| "I'll just use `@SpringBootTest` for everything, it's simpler than picking a slice" | Loads the entire context for every test class, slowing the suite for no coverage benefit when a narrower slice (`@WebMvcTest`/`@DataJpaTest`) already isolates what's under test |
+| "I'll swap in an in-memory H2 database instead of Testcontainers, it's faster" | An in-memory substitute can silently accept a query the real production database would reject or execute differently; use Testcontainers when the project already has it |
+| "This test keeps failing intermittently, I'll just retry it in CI config" | Retrying hides a real determinism bug (often a missing join/await); fix the wait mechanism instead |
+
+## Verification
+
+Do not report the work done until all of the following hold:
+
+- The test file sits at the project's own convention path, matching the
+  slice/assertion style read in Step 1.
+- `./gradlew test`/`mvn test` exits 0 with every generated test passing.
+- `git status` shows only test files added or modified; no source file
+  under test changed.
+- No async wait in a new/changed test uses `Thread.sleep`/`delay`.

package/src/gdskills/bundled/stacks/java-kotlin-spring/skills/java-kotlin-spring-testing/evals.json

@@ -0,0 +1,73 @@
+{
+  "triggers": {
+    "positive": [
+      "OrderCalculator has zero test coverage right now -- can you set up a JUnit 5 suite that exercises the discount logic?",
+      "I want to verify the /orders endpoint returns a 404 with the right error body when the order doesn't exist -- what's the MockMvc setup for that?",
+      "How do I verify my custom findOverdueInvoices query actually returns the right rows, using an in-memory database slice?",
+      "OrderServiceTest started failing after yesterday's refactor and I can't tell if it's a real regression or a stale mock -- can you dig in?",
+      "PricingEngine has a couple of external collaborators I'd rather not spin up for a unit test -- can you mock those out and cover the tax calculation paths?",
+      "InventoryService is written in Kotlin and calls two collaborators I want stubbed out -- what does a solid mocking-based unit test for it look like?",
+      "I don't trust the H2 in-memory results for this repository's native query -- can we spin up a real Postgres container for the test instead?"
+    ],
+    "negative": [
+      "Write pytest tests for this Python function",
+      "Add Jest tests for this React component",
+      "Write table-driven Go tests for this parser",
+      "Add Rust unit tests for this crate",
+      "Review this Spring service for goroutine-style concurrency issues",
+      "Implement a new Spring Boot endpoint that calls this repository"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "no-sleep-awaitility",
+      "prompt": "My Spring test kicks off an async @Async method and I want to wait for it to finish before asserting. What's the right way in this Spring Boot test?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer waits for the async result using an actual synchronization/polling mechanism -- Awaitility's await().atMost(...).until(...), a CompletableFuture join, or a CountDownLatch -- rather than a fixed Thread.sleep delay used as the wait mechanism, whether alone or as extra insurance alongside a real wait.",
+          "pass_criteria": [
+            "Names a concrete synchronization mechanism -- Awaitility, a CompletableFuture join, or a CountDownLatch -- shown concretely, not just 'wait for it to finish' in the abstract.",
+            "Explains why this is reliable/deterministic compared to a fixed delay (it doesn't depend on how long the async method happens to take)."
+          ],
+          "fail_criteria": [
+            "Recommends Thread.sleep as the wait mechanism, whether as the sole way to wait or as additional insurance alongside a real synchronization mechanism. Mentioning Thread.sleep only to warn against it is not a failure."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Use Awaitility: `await().atMost(Duration.ofSeconds(2)).until(() -> repository.findById(id).isPresent())` (or whatever condition marks the async work as done) -- it polls the condition instead of guessing a fixed delay, so the test passes as soon as the condition is true and fails clearly if it never becomes true within the timeout. If the @Async method itself returns a `CompletableFuture`, you can instead just call `.get(2, TimeUnit.SECONDS)` on it directly in the test and assert on the result once it resolves. Either way, avoid Thread.sleep for this -- a fixed sleep either wastes time when the async work finishes early or flakes under CI load when it doesn't finish within your guessed window.",
+        "known_wrong": "Easiest way is to just add `Thread.sleep(500)` right after triggering the async call, then run your assertions -- that gives it enough time to complete in almost every case without pulling in Awaitility or restructuring the method to return a Future just for a test. If it's still flaky in CI sometimes, bump it up to `Thread.sleep(2000)`.",
+        "vague": "Wait for the async method to actually finish before asserting instead of just guessing how long it'll take.",
+        "subtle_wrong": "Use Awaitility for the polling: `await().atMost(Duration.ofSeconds(2)).until(() -> repository.findById(id).isPresent())` -- that's the reliable part. If it's still occasionally flaky in CI, add a small `Thread.sleep(200)` right before the await() call too, just to give the async method a head start before polling begins."
+      },
+      "anti_patterns": ["Thread.sleep"]
+    },
+    {
+      "id": "narrowest-test-slice",
+      "prompt": "I need to add tests for a new Spring @RestController that calls a service to fetch an order. Should I use @SpringBootTest?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer recommends the narrowest slice that actually covers a controller -- @WebMvcTest with MockMvc and the service mocked via @MockitoBean -- instead of @SpringBootTest, and explains that @SpringBootTest loads the whole application context and is unnecessary/slower for testing just the web layer's request/response mapping.",
+          "pass_criteria": [
+            "Recommends @WebMvcTest (with MockMvc) rather than @SpringBootTest for testing this controller.",
+            "States that the service dependency should be mocked (e.g. via @MockitoBean, or @MockBean only on a project pinned below Spring Boot 3.4) rather than using the real service or the full application context.",
+            "States a concrete reason @SpringBootTest is the wrong choice here -- it loads the entire application context and is slower/broader than what testing a controller's request/response mapping needs."
+          ],
+          "fail_criteria": [
+            "Recommends @SpringBootTest as the right or default choice for testing this controller's request/response mapping, without a stated reason the wider context is actually needed here."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "No -- for testing a single controller's request/response mapping, `@WebMvcTest(OrderController.class)` is the better fit. It loads only the web layer (Spring MVC infrastructure, your controller, message converters, validation), not the full application context, so it starts faster and keeps the test focused on what a controller test should actually check: routing, status codes, request/response body shape, and validation errors. Mock the service dependency with `@MockitoBean` (Spring Boot's own `@MockBean` is deprecated since Boot 3.4 and removed in 4.x -- only use it on a project still pinned below 3.4) and use `MockMvc` to perform the request and assert on the result -- you don't need a real service implementation or a database for this. Reach for `@SpringBootTest` only when you actually need the full wired context -- for example, a true end-to-end test spanning multiple layers -- which isn't what's being described here.",
+        "known_wrong": "Yes, just use `@SpringBootTest` -- it boots the full application context so you know everything is wired correctly, including the real service and repository, which gives you more confidence than a narrower slice would. You can autowire the real `OrderController` and `MockMvc` through `@AutoConfigureMockMvc` and test it the same way; there's no real downside to using the full context by default, it's simpler to reach for one annotation everywhere instead of picking between different test slices.",
+        "vague": "Pick whichever Spring test setup makes sense for testing this controller and keep it reasonably fast.",
+        "subtle_wrong": "You could use @WebMvcTest, but honestly @SpringBootTest with @AutoConfigureMockMvc works just as well here and is one less thing to think about when choosing between slices -- it's a bit slower per test class, but for a single new controller that's not going to matter much, and you still get MockMvc the same way. I'd just default to @SpringBootTest for controller tests going forward unless the suite's startup time becomes a real problem."
+      }
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/kotlin-android/agent-refs.json

@@ -0,0 +1,4 @@
+{
+  "agents": [],
+  "note": "no pair -- honest DeepSeek deepseek-chat runner+judge gate (trials=10, strictness=high, flow 336) fails all 4 skills on trigger accuracy alone, never on behavior (every behavior scenario clears the 0.8 floor, mostly 1.0/1.0): compose-implementation TP 3/7 FP 0/7, kotlin-android-testing TP 3/7 FP 0/7, kotlin-android-code-review TP 4/7 FP 0/7, kotlin-android-build-fix TP 4/7 FP 0/7 (this pack's best trigger recall of the four batch-4 packs, and zero false positives across all 4 skills, but still short of the pass bar). Genuine routing weakness against a crowded catalog, not an authoring defect -- stays experimental per flow 336's stack-pack-lessons.md rule against tuning descriptions to restate failing eval prompts."
+}