openssl-jostle

Add a one-line `// Exercises interface/<tree>/util/<file>.c:<line>` comment to each Java OPS test linking it to the exact C-side fault-injection site it drives (tree is `fips` for FIPS tests, `nonfips` otherwise). Use this skill whenever the user wants to make the OPS test → C source mapping traceable — including phrases like "annotate OPS tests", "link OPS tests to their C sites", "add file:line comments to ops tests", "show which OpenSSL call each ops test fires", "document the C location each ops test exercises", "trace ops tests back to C", and similar. Useful after adding new OPS instrumentation, or after C-side edits shift line numbers and existing annotations need refreshing.

Map every instrumented (OPS_*) and typed (JO_*) error-handling branch in Jostle's C trees to concrete test evidence — errorAt offsets, raw-code literals, JO_* constant references, and `// Exercises` anchors — and report orphaned branches no test drives. Use this skill whenever the user wants to verify error-path test coverage — including phrases like "are all the error handling blocks tested", "which error branches have no test", "audit error branch coverage", "find untested OPS sites", "is every typed error code covered by a limit or ops test", "orphaned error branches", and similar. Complements audit-openssl-ops-coverage / audit-jni-ops-coverage (which find UNinstrumented checks): this skill finds instrumented-but-untested ones. Run before declaring a C change done, after adding error codes, and after review-application sweeps.

Verify the interface/nonfips and interface/fips native trees honour the twin discipline — byte-identical files everywhere except the sanctioned divergence list (rand.c, rand.h, jostle_lib_ctx.c, bc_err_codes.h, the fips-only/nonfips-only file sets) — and report unsanctioned drift with sync commands. Use this skill whenever the user wants the two trees checked or synchronized — including phrases like "check tree parity", "did the fips tree get the fix", "are the twins in sync", "audit fips/nonfips drift", "sync the trees", "cross-tree check", and similar. Run after ANY edit to interface/ (both-tree fixes are applied deliberately, never automatically) and before declaring a native change done.

Run Jostle's full test matrix (base test, unitTest25JNI/FFI, integrationTest25JNI/FFI) with forced execution and the FIPS module wired, then verify the result XML proves it — zero failures AND no FIPS-gated class wholesale-skipped. Use this skill whenever the user wants the suite run and trusted — including phrases like "run the full test matrix", "run all the tests including FIPS", "verify everything is green", "did the FIPS tests actually run", "full verification pass", "declare the branch green", and similar. Exists because gradle does not treat TEST_FIPS_LIB as a task input: a cached green run silently replays wholesale-skipped FIPS classes in milliseconds.

How to add a new JCE / JCA algorithm or transformation to the OpenSSL Jostle provider (Cipher, Signature, KeyAgreement, SecretKeyFactory, KeyPairGenerator, KeyFactory, Mac, MessageDigest, KEM, KDF). Make sure to use this skill whenever the user asks to add, register, wire up, expose, or hook a new cryptographic algorithm into Jostle's JCE surface — including phrases like "add support for X", "expose Y as a Cipher transformation", "register Z in the provider", "wire up an X9.63 KDF", "implement HKDF", "add Chacha20 support", "add an ML-KEM variant", and similar. Also applies when the user wants to add a new OID alias on an existing transformation, add a new SPI hierarchy, or build out the native bridge for a JCE primitive.

Scan Jostle's JNI bridge sources for JVM access calls (GetStringUTFChars, GetByteArrayElements, load_bytearray_ctx, etc.) whose return values are checked in an `if (...)` but lack `OPS_FAILED_ACCESS_*` fault-injection instrumentation. Use this skill whenever the user wants to audit OPS test coverage of JNI access failure paths — including phrases like "find missing JNI OPS tests", "audit JNI OPS coverage", "which JNI access calls have no OPS instrumentation", "check for uninstrumented JNI access faults in <file>", "review JNI bridge for OPS gaps", "what JNI calls aren't covered by ops tests", "where do we need OPS_FAILED_ACCESS instrumentation", and similar. Also applies when the user wants to know if a specific JNI bridge file has full OPS coverage of its `(*env)->` access points before declaring a feature done.

Scan Jostle's C sources for OpenSSL function calls whose return values are checked in an `if (...)` but lack `OPS_*` fault-injection instrumentation. Use this skill whenever the user wants to audit OPS test coverage of error paths in C code — including phrases like "find missing OPS tests", "audit OPS coverage", "which OpenSSL calls have no OPS instrumentation", "check for uninstrumented error paths in rsa.c", "review C code for OPS gaps", "what OpenSSL calls aren't covered by ops tests", "where do we need more OPS tests", and similar. Also applies when the user wants to know if a specific .c file has full OPS coverage before declaring a feature done.

Regenerate SERVICES.md (a markdown inventory of every algorithm the Jostle provider registers, grouped by JCA service type — KeyFactory, Cipher, Signature, KeyStore, Mac, MessageDigest, …) by running the DumpInfo diagnostic with its --services flag and parsing the output. Use this skill whenever the user wants to refresh or produce the provider's service list — including phrases like "update SERVICES.md", "regenerate the services list", "list provider services", "dump the services", "what algorithms does the provider register", "refresh the services inventory". Also useful after adding, removing, or renaming a service registration in a Prov<NAME>.configure(...) class, or after pulling changes that may have altered the registered algorithm set.

Scan Jostle's unit-test tree for two recurring discipline gaps — roundtrip tests that use hardcoded keys/messages instead of random inputs, and roundtrip tests with no negative-path differentiator (tampered ciphertext, tampered signature, wrong key, distinct inputs producing distinct outputs). Use this skill whenever the user wants to audit test discipline — including phrases like "audit test coverage", "find tests with hardcoded keys", "check tests for negative-path coverage", "scan for tests that need random inputs", "verify tests have tamper checks", "find tests that don't randomise inputs", and similar. Also useful before declaring a new test file done, after a refactor that changed input-derivation patterns, or as part of a broader test-quality sweep.