@mrciphersmith/keryx 0.3.5 → 0.3.7

package/src/gdskills/bundled/stacks/rust/skills/rust-code-review/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: rust-code-review
+description: "Use when reviewing a Rust change for ownership, panic, and safety risks -- unwrap/expect on fallible input, unnecessary clone as a borrow-checker workaround, unjustified or oversized unsafe blocks, blocking calls in async fn, unchecked arithmetic/indexing on untrusted data, and error types that lose their source. Read-only, no edits."
+triggers:
+  - "review this Rust diff for unwrap panics"
+  - "check this Rust change for unsafe block safety"
+  - "review this Rust patch for blocking calls in async fn"
+  - "any unnecessary clones in this Rust change"
+  - "check this Rust code for integer overflow on untrusted input"
+  - "review this Rust diff for error handling that drops the source"
+  - "audit this Rust module for a panic reachable from untrusted input"
+metadata:
+  origin: authored
+  category: review
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Rust code review
+
+Read-only review of a Rust change for ownership, panic, and safety risks
+specific to Rust: `.unwrap()`/`.expect()` on fallible or untrusted input,
+a borrow-checker `.clone()` workaround, unjustified `unsafe`, blocking
+calls in `async fn`, unchecked arithmetic/indexing, and error types that
+lose their source. This skill never edits code — it reports findings.
+`rules/coding-style.mdc`, `rules/patterns.mdc`, and `rules/security.mdc`
+are the rule set findings are checked against.
+
+## Workflow
+
+### Step 1: Scope the review
+
+1. Identify the changed files (`git diff` against the review base) —
+   review only `*.rs` files in the diff, not the whole crate.
+2. Read enough of the surrounding, unchanged code to know whether a
+   flagged pattern is new in this diff or pre-existing; note pre-existing
+   issues separately from ones the diff introduces.
+
+### Step 2: Check each changed function against the focus list
+
+**Panics on fallible/untrusted input**
+- `.unwrap()`/`.expect()` on a `Result`/`Option` built from network input,
+  file contents, CLI arguments, a map lookup on external data, or any
+  other fallible/attacker-influenced source — flag it; the fix is `?`, a
+  `match`, or a combinator, not a panic on bad input.
+- Raw array/slice indexing (`arr[i]`) on an index derived from untrusted
+  input instead of `.get(i)` — flag as a potential panic/DoS.
+- Unchecked arithmetic (`a + b`, `a * b`) on values that can be
+  attacker-influenced instead of `checked_*`/`saturating_*`/`wrapping_*`
+  chosen for the operation's actual semantics.
+
+**Ownership and cloning**
+- A `.clone()` added specifically to route around a borrow-checker error,
+  with no comment explaining why the duplication is actually needed —
+  flag as a possible design smell per `rules/patterns.mdc`; note when
+  restructuring ownership or borrowing differently looks feasible from
+  the diff alone.
+
+**`unsafe` blocks**
+- Any `unsafe` block with no `# Safety` doc comment stating the invariant
+  it relies on — flag it.
+- An `unsafe` block wider than the specific operation that requires it —
+  flag as unnecessarily large audited surface.
+
+**Async and concurrency**
+- A blocking call (`std::thread::sleep`, synchronous `std::fs`/`std::net`
+  I/O, a `std::sync::Mutex` guard held across an `.await`) inside an
+  `async fn` — flag as a potential executor stall.
+- A spawned task (`tokio::spawn`) with no visible join (`.await` on its
+  `JoinHandle`, or a channel) — flag as fire-and-forget with no stated
+  reason.
+
+**Error handling**
+- A custom error variant that discards the underlying cause (a bare
+  `String` built from `.to_string()` on the source error, with no
+  `#[source]`/`#[from]`) — flag as losing information a caller could
+  otherwise inspect.
+
+### Step 3: Report
+
+For each finding: file:line, the pattern, why it matters (panic, leak,
+unsound `unsafe`, executor stall), and the fix direction — but do not
+apply it.
+
+```
+src/order/service.rs:58 — .unwrap() on the downstream client's Result,
+  which carries a network call's outcome. Risk: a downstream failure
+  panics the process instead of propagating. Fix direction: propagate
+  with ? into this module's OrderError, or add a #[source]-wrapping
+  variant if one doesn't exist yet.
+```
+
+## Rules
+
+- NEVER edit code — findings and fix direction only.
+- Flag `.unwrap()`/`.expect()` on fallible/untrusted input, unnecessary
+  clones, unjustified/oversized `unsafe`, blocking calls in `async fn`,
+  unchecked arithmetic/indexing on untrusted data, and error types that
+  drop their source; do not report generic style nits already covered by
+  `rustfmt`/`clippy`'s default lint set (those are noise here).
+- Distinguish a finding the diff introduces from a pre-existing one in
+  code the diff merely touches.
+- When a suspected data race or unsoundness is not certain from reading
+  alone, say "run under `cargo miri test` / `loom` to confirm" rather than
+  asserting it without evidence.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "This `.unwrap()` is on input the caller always validates first" | That invariant lives in a different function the diff may not show; flag it and ask for the validation to be visible at this call site, or a comment stating the invariant |
+| "It's just a config map, it's only cloned once at startup" | A clone whose need is not stated in a comment is still a design smell worth naming, even if the current call site is cheap |
+| "I'll just fix the unwrap myself since it's a one-line change" | This skill is read-only; report the finding and its fix direction, do not edit the file |
+| "The unsafe block is small, it doesn't need a Safety comment" | Size does not establish soundness; the comment is what lets a reviewer (or future maintainer) check the invariant without re-deriving it |
+
+## Verification
+
+Do not report the review done until all of the following hold:
+
+- Every changed `*.rs` file in the diff was read, not just files named in
+  the PR description.
+- Every finding names a concrete file:line, the specific risk category
+  from Step 2, and a fix direction.
+- No source file was modified by this review.
+- Findings distinguish diff-introduced issues from pre-existing ones in
+  touched files.

package/src/gdskills/bundled/stacks/rust/skills/rust-code-review/evals.json

@@ -0,0 +1,72 @@
+{
+  "triggers": {
+    "positive": [
+      "Review this Rust pull request for unwrap panics on untrusted input",
+      "Check this Rust diff for unsafe blocks missing a Safety comment",
+      "Does this Rust change block the tokio runtime inside an async fn?",
+      "Review this Rust concurrency change for unjoined spawned tasks",
+      "Check for unnecessary clones used as a borrow-checker workaround in this Rust diff",
+      "This error enum has a variant that stores just a String instead of wrapping the original error -- is that going to bite us later, can you check the diff?"
+    ],
+    "negative": [
+      "Review this Rust code and also fix the bugs you find",
+      "Review this Python code for SQL injection",
+      "Review this Go diff for goroutine leaks",
+      "Implement a bounded async worker pool in this Rust crate using tokio",
+      "Run a general security review on this codebase",
+      "Review this Rust diff for naming conventions and formatting only"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "read-only-unwrap-review",
+      "prompt": "Review this Rust diff: a new function calls `response.json::<Payload>().await.unwrap()` on an HTTP client's response. What do you find?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies the .unwrap() on the HTTP response's Result as the problem, explains why it's wrong (the network response is fallible/untrusted input and a malformed or unexpected body will panic the process instead of returning an error), and reports this as a finding with a fix direction -- it never actually edits or claims to have edited the code, even partially, since this skill is read-only.",
+          "pass_criteria": [
+            "Identifies the `.unwrap()` on `response.json::<Payload>().await` as the problem, naming the specific call from this diff.",
+            "Explains that a network response is fallible/untrusted input, so a malformed or unexpected body panics the process instead of being handled.",
+            "Names the concrete fix direction: propagate with `?` (into the function's Result/error type) or handle the Err case explicitly, presented purely as a finding with no code change applied or described as already made."
+          ],
+          "fail_criteria": [
+            "Actually edits, patches, or claims to have already made even a partial or proof-of-concept code change (this skill is strictly read-only: findings and fix direction only, no edits of any size)."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Finding: `response.json::<Payload>().await.unwrap()` panics the whole process if the HTTP response body doesn't deserialize into `Payload` -- a malformed response, an unexpected error page, or a schema change on the other end all turn into a panic here instead of a handled error, even though this is exactly the kind of externally-influenced, fallible input `.unwrap()` should never be used on. Fix direction: propagate the `Result` with `?` (converting into whatever error type this function already returns, via a `#[from]`-wrapping thiserror variant if one exists, or adding one) so a deserialization failure becomes a normal `Err` the caller can handle, rather than a panic. I'm reporting this as a finding with that fix direction rather than making the change myself, since this review is read-only.",
+        "known_wrong": "This `.unwrap()` is a minor nit -- the API contract for this endpoint is pretty stable, so I went ahead and changed it to `.expect(\"payload should deserialize\")` directly in the diff so there's at least a message if it ever does panic, and left a comment noting the endpoint's schema is unlikely to change. That should be good to merge as-is.",
+        "vague": "That unwrap on the response looks like it could be risky if the payload doesn't parse -- might be worth reconsidering before this merges.",
+        "subtle_wrong": "Finding: `.unwrap()` on the deserialized response will panic if `Payload` doesn't match the body -- worth fixing. I went ahead and made a small proof-of-concept edit swapping it for `.expect(\"payload should match Payload\")` so you can see the shape of a clearer panic message, though the caller would still need to decide how it wants to handle an actual parse failure before this is really done."
+      }
+    },
+    {
+      "id": "unsafe-missing-safety-comment",
+      "prompt": "Review this Rust diff: a new `unsafe` block dereferences a raw pointer passed in from an FFI caller, with no comment above it. What's wrong?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies that the unsafe block has no # Safety doc comment stating the invariants the caller must uphold (pointer validity, non-null, alignment, lifetime) for the dereference to be sound, flags this as a review finding with a fix direction (add a # Safety comment naming the specific invariant, and validate what can be checked at runtime before the FFI boundary), and does not apply the fix itself since this skill is read-only. It does not accept 'the unsafe block is small/obviously fine' as a substitute for stating the invariant.",
+          "pass_criteria": [
+            "Identifies specifically that the unsafe block lacks a # Safety doc comment naming the invariants required for the raw pointer dereference to be sound.",
+            "Names at least one concrete invariant that comment should state (non-null, valid, properly aligned, or a lifetime/ownership contract) relevant to an FFI-supplied raw pointer.",
+            "Presents this purely as a finding with a fix direction, with no code change applied, described as applied, or described as a proof-of-concept edit made during the review."
+          ],
+          "fail_criteria": [
+            "Dismisses the missing # Safety comment as unnecessary because the unsafe block is small or the dereference looks obviously fine, instead of requiring the invariant to be stated explicitly."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Finding: the `unsafe` block dereferences a raw pointer that came from an FFI caller, but carries no `# Safety` doc comment. That's a problem specifically because this pointer crosses an FFI boundary -- unlike a pointer derived from safe Rust, there's no compiler guarantee it's non-null, valid, or properly aligned, and nothing here states what the caller is actually required to uphold. Fix direction: add a `# Safety` doc comment on the function or the block itself naming the concrete invariant (e.g. \"caller must ensure `ptr` is non-null, points to a valid, properly aligned `Payload`, and remains valid for the duration of this call\"), and where feasible, add a runtime null-check before the dereference since that much can actually be verified rather than just documented. I'm flagging this as a finding with that fix direction rather than adding the comment myself, since this review is read-only.",
+        "known_wrong": "The unsafe block is only dereferencing one pointer and the surrounding code looks straightforward, so I don't think this needs a Safety comment -- it's pretty obviously fine from reading it. I'd let this merge as-is; adding a comment here would mostly be restating what the code already does rather than adding real information.",
+        "vague": "That unsafe block could use a bit more documentation about what it assumes -- might be worth tightening up before this merges.",
+        "subtle_wrong": "Finding: the unsafe block has no comment above it. I went ahead and added a short `// SAFETY: ptr is assumed valid` note directly above the block in the diff so reviewers have something to read, though it doesn't spell out non-null/alignment/lifetime specifically -- that level of detail probably isn't necessary for a pointer that's just being read once."
+      }
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/rust/skills/rust-implementation/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: rust-implementation
+description: "Use when implementing or extending a feature in a Rust crate -- Cargo.toml/edition/workspace layout, ownership and borrowing, Result/Option error handling with the ? operator, thiserror/anyhow conventions, trait and generic design, and avoiding blocking calls in async fn."
+triggers:
+  - "implement this feature in Rust"
+  - "add a Rust module to this crate under src/"
+  - "propagate this Rust error with the ? operator"
+  - "add a thiserror error enum for this Rust module"
+  - "write this as an async fn in Rust without blocking the runtime"
+  - "design this Rust trait so callers can't over-implement it"
+  - "implement this Rust struct with a builder pattern"
+metadata:
+  origin: authored
+  category: implement
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Rust implementation (2021/2024 edition)
+
+Implement or extend a feature in a Rust crate: workspace/module layout,
+ownership and borrowing, error handling with `Result`/`?`, trait and
+generic design, and safe async idiom. Scoped to Rust specifically —
+`rules/coding-style.mdc`, `rules/patterns.mdc`, and `rules/security.mdc`
+carry the full stack-specific rule set this skill draws its checklist
+from; read them before writing code, not just this summary.
+
+## Workflow
+
+### Step 1: Discover the project's own conventions
+
+1. Read `Cargo.toml` for the crate/workspace name, the `edition` (2021 vs
+   2024), and whether a `rust-version` (MSRV) is pinned — do not use a
+   language feature newer than what's declared.
+2. Find the existing layout: `src/lib.rs`/`src/main.rs`, module
+   boundaries, whether this is a `[workspace]` with multiple member
+   crates. Match it; do not invent a different layout for one change.
+3. Read 1-2 neighboring files in the module you are touching for: error
+   handling style (`thiserror` enum vs `anyhow::Result`), whether the
+   crate is async (`tokio` in `Cargo.toml`'s dependencies) and which
+   runtime, existing trait boundaries, and the crate's own newtype/builder
+   conventions.
+
+### Step 2: Design before writing
+
+- Decide ownership shape per function: does it need `&self`, `&mut self`,
+  or `self` by value? Does a parameter need to own its argument or can it
+  borrow (`&str` over `String`, `&[T]` over `Vec<T>`)?
+- Decide the error shape: a library module gets a `thiserror`-derived enum
+  with `#[source]`/`#[from]` on wrapping variants; an application/binary
+  entry point uses `anyhow::Result` with `.context(...)` at each
+  meaningful `?`.
+- For any new trait, decide who the consumer is and size the trait to
+  exactly what that consumer calls (`rules/patterns.mdc`); decide
+  `impl Trait` vs `Box<dyn Trait>` based on whether runtime polymorphism
+  is actually needed.
+- If the crate is async, trace which calls on the new path are I/O-bound
+  (use the async equivalent) versus CPU-bound/blocking (route through
+  `tokio::task::spawn_blocking`).
+
+### Step 3: Implement
+
+1. Borrow instead of clone by default (`rules/coding-style.mdc`); when a
+   `.clone()` is genuinely necessary, say why in a comment if it is not
+   obvious.
+2. Propagate errors with `?`; never reach for `.unwrap()`/`.expect()` on a
+   `Result`/`Option` built from fallible or untrusted input.
+3. Derive `Debug`/`Clone`/`PartialEq`/etc. where the fields support it
+   instead of hand-writing boilerplate impls.
+4. Keep any `unsafe` block minimal and carrying a `# Safety` doc comment
+   stating the exact invariant it relies on (`rules/security.mdc`).
+5. Format with `cargo fmt` as you go, not as an afterthought.
+
+### Step 4: Verify
+
+```bash
+cargo build --all-targets
+cargo clippy --all-targets -- -D warnings
+cargo fmt --check
+cargo test
+```
+
+Fix findings at the root cause per `rules/security.mdc` and
+`rules/coding-style.mdc`; a build/clippy/test failure at this step is a
+signal to fix the implementation, not to reach for `rust-build-fix`'s
+scope unless the failure is a build/dependency/module-resolution problem
+unrelated to the feature logic.
+
+### Step 5: Report
+
+```
+Implemented: src/order/service.rs, src/order/error.rs
+  - New OrderError enum (thiserror) wraps the downstream client's error
+  - cargo build/clippy -D warnings/fmt --check/test all pass
+```
+
+## Rules
+
+- ALWAYS propagate a fallible `Result`/`Option` with `?` or an explicit
+  match/combinator; NEVER call `.unwrap()`/`.expect()` on one built from
+  fallible or untrusted input without a stated, verified invariant that
+  makes it truly infallible.
+- ALWAYS give an `unsafe` block a `# Safety` doc comment naming the
+  invariant it relies on; NEVER widen an `unsafe` block or drop that
+  comment to silence a compiler/clippy complaint.
+- NEVER call a blocking operation (`std::thread::sleep`, a synchronous
+  file/socket read, a `std::sync::Mutex` held across `.await`) inside an
+  `async fn` on a multi-threaded runtime; use the async equivalent or
+  `spawn_blocking`.
+- Match the project's declared `edition`/`rust-version` — do not use a
+  language feature newer than what `Cargo.toml` targets.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "The borrow checker is fighting me here, I'll just `.clone()` to move on" | A reflexive clone hides an ownership design question (`rules/patterns.mdc`); consider restructuring or borrowing before paying the copy on every call |
+| "This `.unwrap()` is fine, the input should always be valid" | "Should" is not "is" — untrusted or fallible input that turns out invalid panics the process; propagate with `?` instead |
+| "It's a quick synchronous call inside this async fn, it won't block long" | Any blocking call on a multi-threaded async runtime can stall the executor's worker thread for every other task scheduled on it, not just this one |
+| "I'll skip the `# Safety` comment, the unsafe block is obviously fine" | "Obviously fine" is exactly what an unsafe review cannot take on faith; state the invariant so it can be checked |
+
+## Verification
+
+Do not report the work done until all of the following hold:
+
+- `cargo build --all-targets`, `cargo clippy --all-targets -- -D warnings`,
+  `cargo fmt --check`, and `cargo test` all exit 0.
+- Every new/touched `Result`/`Option` from fallible or untrusted input is
+  propagated with `?` or handled explicitly, not `.unwrap()`/`.expect()`'d.
+- Every new `unsafe` block carries a `# Safety` doc comment.
+- No blocking call was introduced inside an `async fn` without
+  `spawn_blocking` or an async equivalent.

package/src/gdskills/bundled/stacks/rust/skills/rust-implementation/evals.json

@@ -0,0 +1,79 @@
+{
+  "triggers": {
+    "positive": [
+      "Implement a new Rust module under src/order that propagates errors with the ? operator",
+      "My PaymentClient call can fail and I'm currently just unwrapping it -- what's the idiomatic way to wrap that failure into my own error type while keeping the original cause?",
+      "Write this Rust function so it borrows instead of cloning to satisfy the borrow checker",
+      "Implement an async fn in Rust that fetches from a downstream service without blocking the tokio runtime",
+      "I'm defining a new trait for this client -- how big should it be, and who should it actually be implemented for?",
+      "My RequestConfig struct has six optional fields and constructing it with Some/None everywhere is getting ugly -- what's a cleaner way to build it up incrementally?",
+      "Add error handling to this Rust CLI using anyhow::Result and .context()"
+    ],
+    "negative": [
+      "Implement this feature in Go using errgroup for the worker pool",
+      "Add this endpoint in a Python FastAPI service",
+      "Implement this React component with the new form fields",
+      "Review this Rust diff for unsafe blocks and unwrap panics",
+      "Fix this failing cargo test in the order crate",
+      "Write table-driven Go tests for this function",
+      "Implement this feature in Rust but skip error handling for now",
+      "Which smart pointer should own this object in modern C++, unique_ptr or shared_ptr?"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "error-propagation-thiserror",
+      "prompt": "I'm adding a new function to a Rust library crate that calls a downstream client. How should I handle the Result and the error it can return?",
+      "strictness": "high",
+      "expected_behavior": [
+        { "grader": "regex", "value": "\\?" },
+        {
+          "grader": "judge",
+          "rubric": "A correct answer propagates the downstream client's fallible call with the ? operator rather than unwrapping it, and defines (or extends) a thiserror-derived error enum with a variant carrying #[source] or #[from] so the downstream error's cause is preserved for callers, rather than calling .unwrap()/.expect() on the Result or collapsing the failure into an opaque string.",
+          "pass_criteria": [
+            "Shows propagating the downstream call's Result with the ? operator, not .unwrap()/.expect() or a manual match that discards the error.",
+            "Names a concrete thiserror enum variant with #[source] or #[from] wrapping the downstream error (e.g. `Downstream(#[from] DownstreamError)`), not just 'handle the error properly'.",
+            "Explains that this preserves the original cause so callers can inspect it (via source() or the #[from] conversion), not merely that 'the error is handled'."
+          ],
+          "fail_criteria": [
+            "Recommends calling .unwrap() or .expect() on the downstream call's Result instead of propagating it with ? or an explicit match. Mentioning .unwrap()/.expect() only to warn against using it on fallible/untrusted input is not a failure."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Propagate the downstream call with `?` rather than unwrapping it -- add a variant to this module's `thiserror`-derived error enum, something like `#[error(\"downstream call failed\")] Downstream(#[from] DownstreamError)`, so the `?` operator converts the downstream error into your own error type automatically via the generated `From` impl. The `#[from]` attribute also marks the field as `#[source]`, so `std::error::Error::source()` returns the original downstream error -- a caller further up can still inspect what actually went wrong instead of just seeing your wrapper's message. Don't reach for `.unwrap()`/`.expect()` here even though it would compile faster to write -- a downstream call is exactly the kind of fallible, externally-influenced operation that should never panic the process on failure.",
+        "known_wrong": "Since this is calling a downstream client I trust to basically always succeed, I'd just `.unwrap()` the Result and move on -- it keeps the function signature simple and avoids growing the error enum for a case that's rare in practice. If you're worried about it, you could `.expect(\"downstream call should succeed\")` instead so there's at least a message in the panic output, but either way there's no need to wrap it in your own error type or preserve the source chain for something this unlikely to fail.",
+        "vague": "Handle the error from the downstream call properly and make sure it's propagated correctly to the caller.",
+        "subtle_wrong": "Propagate it with `?` like this: add a `Downstream(String)` variant to your error enum and convert with `.map_err(|e| MyError::Downstream(e.to_string()))?` at the call site -- that keeps the enum simple (no need to pull in `#[source]`/`#[from]` or worry about the downstream error type implementing `std::error::Error`) while still returning a proper `Result` instead of unwrapping. Callers get a readable message either way."
+      },
+      "anti_patterns": [".unwrap()"]
+    },
+    {
+      "id": "async-blocking-call",
+      "prompt": "I need to write an async fn in a tokio-based Rust service that reads a config file and then sleeps briefly between retries. What should I watch out for?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies that both the file read and the sleep must use tokio's async equivalents (tokio::fs::read/read_to_string and tokio::time::sleep) rather than the synchronous std::fs or std::thread::sleep, because a blocking call inside an async fn running on tokio's multi-threaded runtime can stall the worker thread and every other task scheduled on it -- not just this one -- and, if a genuinely CPU-bound or unavoidably-blocking operation is needed, routes it through tokio::task::spawn_blocking instead of calling it directly.",
+          "pass_criteria": [
+            "Names tokio::fs (e.g. tokio::fs::read or read_to_string) instead of std::fs for the config file read inside the async fn.",
+            "Names tokio::time::sleep instead of std::thread::sleep for the retry delay.",
+            "Explains the concrete consequence of blocking on a multi-threaded tokio runtime -- that it can stall the executor's worker thread for other tasks, not merely that it 'blocks the function'."
+          ],
+          "fail_criteria": [
+            "Recommends std::thread::sleep for the retry delay inside the async fn, whether alone or alongside the correct tokio::fs read. Mentioning std::thread::sleep only to warn against it is not a failure.",
+            "Recommends a synchronous std::fs read inside the async fn and dismisses it as fine because the file is small or the read is quick."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Use `tokio::fs::read_to_string(path).await` for the config file instead of `std::fs::read_to_string` -- the std version is a synchronous, blocking syscall, and calling it directly inside an `async fn` running on tokio's multi-threaded runtime can stall the worker thread that task is scheduled on, which stalls every other task tokio happens to schedule on that same thread too, not just this one. For the delay between retries, use `tokio::time::sleep(duration).await`, not `std::thread::sleep` -- `std::thread::sleep` blocks the OS thread for its whole duration with no way for the runtime to schedule other work on it, while `tokio::time::sleep` yields the task back to the executor and only wakes it when the timer fires. If you ever do need a genuinely CPU-bound or unavoidably-blocking call on this path, wrap it in `tokio::task::spawn_blocking(|| ...)` so it runs on tokio's dedicated blocking thread pool instead of a regular async worker thread.",
+        "known_wrong": "For something this small it's simpler to just use `std::fs::read_to_string` for the config -- it's one quick read at startup-ish time, not worth pulling in the async file API for. Same for the retry delay: `std::thread::sleep(duration)` is fine here since it's just a brief pause between attempts and the function isn't handling other work at that exact moment anyway, so blocking the thread for a few hundred milliseconds isn't really a problem in practice.",
+        "vague": "Make sure you use the async-friendly versions of file reading and sleeping so you don't block the runtime.",
+        "subtle_wrong": "Use `tokio::time::sleep(duration).await` for the retry delay -- that part's important since it yields back to the executor instead of blocking the thread. For the config file, `std::fs::read_to_string` is fine to leave as-is though, since it's a small local file and the read itself finishes in well under a millisecond, so it's not going to noticeably stall anything on the runtime even though it's technically a blocking call."
+      },
+      "anti_patterns": ["std::thread::sleep"]
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/rust/skills/rust-testing/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: rust-testing
+description: "Use when a Rust crate's own test suite needs writing, extending, or fixing with cargo test -- #[cfg(test)] unit tests, tests/ integration tests, multi-case assertions built as a Vec of structs, #[tokio::test] async tests joined properly, proptest/quickcheck property-based checks on a Rust struct or enum, and criterion benchmarks."
+triggers:
+  - "write Rust unit tests for this module with cargo test"
+  - "add unit tests in a #[cfg(test)] block"
+  - "fix this failing cargo test in the crate"
+  - "add a proptest for this Rust struct's invariants"
+  - "write a criterion benchmark for this Rust function"
+  - "test this Rust async fn with #[tokio::test]"
+  - "add integration tests under tests/ for this Rust crate"
+metadata:
+  origin: authored
+  category: test
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Rust testing (2021/2024 edition)
+
+Write, extend, or fix a Rust crate's test suite: unit tests, integration
+tests, async tests, property-based tests, and benchmarks. `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 `Cargo.toml`'s `edition`/`rust-version` and dev-dependencies to
+   know what's already available: `tokio` (and its `test-util`/`macros`
+   features for `#[tokio::test]`), `proptest`/`quickcheck`, `criterion`,
+   `serial_test`, `pretty_assertions`.
+2. Find the layout: `#[cfg(test)] mod tests` blocks beside the code, or a
+   `tests/` integration directory. Match whichever the crate already uses
+   for the kind of test you're adding.
+3. Read 1-2 neighboring test modules for: case/table shape, whether an
+   assertion crate is already in use, fixture conventions
+   (`tests/fixtures/` or a local `testdata/`), and whether async tests are
+   already wired with `#[tokio::test]`.
+
+### Step 2: Plan test cases
+
+**Functions:** happy path, edge cases (empty/zero-value/boundary inputs),
+error cases (assert the specific error variant, not just `is_err()`).
+
+**Table-style:** a `Vec`/slice of a local case struct (name, input,
+expected) iterated in one `#[test]` function when several cases share the
+same assertion shape, rather than many near-duplicate test functions.
+
+**Async code:** `#[tokio::test]` for an `async fn` test body; a spawned
+task is joined via `.await` on its `JoinHandle` (or a channel) before
+assertions run.
+
+**Untrusted-input-shaped code (parsers, decoders):** consider `proptest`/
+`quickcheck` for the input space, and note where `cargo fuzz` would apply.
+
+### Step 3: Write
+
+1. Create/extend the test module or `tests/` file at the project's own
+   convention path.
+2. Name each test for the behavior it verifies, not `test1`/`test_x`.
+3. Assert the specific error variant on a `Result`-returning function
+   (`matches!(err, MyError::NotFound { .. })` or `assert_eq!` when the
+   error implements `PartialEq`), not only `result.is_err()`.
+4. Put fixture/golden data under the project's existing convention
+   (`tests/fixtures/` or `testdata/`).
+5. Never synchronize with `std::thread::sleep`/`tokio::time::sleep` to
+   "give a spawned task time to finish" — join its `JoinHandle` or a
+   channel instead.
+
+### Step 4: Property tests and benchmarks (when relevant)
+
+- `proptest!` (or `quickcheck`) macros for a parser/serializer with a
+  large structured input space, generating cases instead of hand-writing
+  dozens of near-identical examples.
+- `criterion`-based benchmarks (`fn bench(c: &mut Criterion)` registered
+  via `criterion_group!`/`criterion_main!`) for anything needing
+  statistical rigor; the unstable built-in `#[bench]` needs nightly and is
+  not the default choice.
+
+### Step 5: Run and fix
+
+```bash
+cargo 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 6: Report
+
+```
+Generated: src/order/service.rs (tests module), tests/order_integration.rs
+  - 7 test cases (4 table-style), all passing under cargo test
+```
+
+## Rules
+
+- ALWAYS match the project's existing test-location/table/assertion
+  conventions found in Step 1, not a different crate's style.
+- NEVER modify source code — only test modules, `tests/` files, and
+  fixture data.
+- NEVER use `std::thread::sleep`/`tokio::time::sleep` to wait for a
+  spawned task or async result instead of joining it.
+- Assert the specific error variant for a `Result`-returning function, not
+  only `is_err()`/`is_ok()`.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll add a short `tokio::time::sleep(Duration::from_millis(50)).await` so the spawned task finishes" | Non-deterministic under load; `.await` the task's `JoinHandle` (or a channel) so the test cannot flake |
+| "This test keeps failing; I'll loosen the assertion to `result.is_err()` without checking which error" | An `is_err()`-only check passes for the wrong failure just as readily as the right one, hiding a regression next time |
+| "criterion is overkill for this, I'll just time it with `std::time::Instant` in a test" | Loses warm-up handling, outlier detection, and run-to-run regression comparison that `criterion` provides for free |
+| "I'll modify the function slightly so this test passes" | This skill only touches test files; a source change belongs in `rust-implementation` or a stated, separately-reported bug fix, not a silent edit while writing tests |
+
+## Verification
+
+Do not report the work done until all of the following hold:
+
+- The test module/file sits at the project's own convention path, matching
+  the table/fixture style read in Step 1.
+- `cargo test` exits 0 with every generated test passing.
+- `git status` shows only test files (and fixture data, if touched) added
+  or modified; no source file under test changed.
+- Every spawned task in a new test is joined (`.await` on its `JoinHandle`,
+  or a channel) before its assertions run.

package/src/gdskills/bundled/stacks/rust/skills/rust-testing/evals.json

@@ -0,0 +1,75 @@
+{
+  "triggers": {
+    "positive": [
+      "I just wrote parse_header and it has zero coverage -- can you set it up with tests the idiomatic way, inline in the same file?",
+      "Add table-style test cases for this Rust validator with a Vec of cases",
+      "`cargo test -p order` is red on main after my last change -- test_reject_duplicate_line_item is failing, can you dig into why and fix it?",
+      "Add a proptest for this Rust parser function",
+      "I want hard numbers before I optimize parse_batch -- what's the right way to measure it so the compiler doesn't just optimize the whole thing away?",
+      "Test this async fn with #[tokio::test] and join the spawned task properly",
+      "Right now only the internals of this crate have coverage -- how do I set up tests that exercise it the same way an external consumer would, calling only what's exported?"
+    ],
+    "negative": [
+      "Write pytest tests for this Python function",
+      "Add Jest tests for this React component",
+      "Review this Rust diff for unwrap panics and unsafe blocks",
+      "Fix the cargo build error in this crate",
+      "Implement a new Rust service that calls this downstream API",
+      "Write Go table-driven tests for this function",
+      "Add unit tests in a Go _test.go file for this package"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "error-variant-assertion",
+      "prompt": "I need to add several test cases for this Rust function that validates an order and returns a Result. How should I structure them and check the error cases?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer structures the cases as a small table -- a Vec or slice of a local struct with fields for the input and the expected outcome -- iterated in one test rather than many near-duplicate test functions, and for the error cases asserts the specific error variant (e.g. with matches! or assert_eq! against a PartialEq error type) rather than only checking result.is_err().",
+          "pass_criteria": [
+            "Uses a table of cases -- a Vec or slice of a struct/tuple per case with input and expected fields -- not one function per case or a long sequence of unrelated asserts.",
+            "Shows the concrete error assertion checking the specific variant (e.g. `assert!(matches!(err, OrderError::MissingId))` or `assert_eq!(err, OrderError::MissingId)`), not only `assert!(result.is_err())`.",
+            "Explains why checking the specific variant matters (it verifies which validation failed, not merely that something failed)."
+          ],
+          "fail_criteria": [
+            "Checks only `result.is_err()`/`result.is_ok()` for the error cases without verifying which specific error variant occurred."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Structure this as a small table: define a local struct with fields like `name: &str`, `order: Order`, and `want: Result<Order, OrderError>`, then build a `Vec` of cases covering the happy path, zero-value/empty-field inputs, and each distinct validation failure. Loop over the cases in one `#[test]` function and compare the actual result against `want`. For the error cases specifically, don't stop at `assert!(result.is_err())` -- that passes just as readily for the wrong error as the right one. Instead assert the specific variant: if `OrderError` derives `PartialEq`, `assert_eq!(result, Err(OrderError::MissingId))` works directly; otherwise use `assert!(matches!(result, Err(OrderError::MissingId)))`. That way the test actually verifies which validation rule caught the bad input, not just that validation returned some `Err`.",
+        "known_wrong": "I'd write a separate `#[test]` function per case -- `fn rejects_missing_id()`, `fn rejects_negative_total()`, `fn accepts_valid_order()`, and so on -- each building its own `Order` and calling `validate`. For the error ones I'd just check `assert!(result.is_err())` -- that's simpler than matching on the specific variant and is good enough to confirm validation caught the bad input; you don't really need to know which exact error came back for a test like this.",
+        "vague": "Structure the test cases in a table and make sure the error cases are checked properly along the way.",
+        "subtle_wrong": "Define a `Vec` of `(name, order, want_err)` tuples covering the cases you need, then loop with `for (name, order, want_err) in cases { let result = validate(order); assert_eq!(result.is_err(), want_err, \"{name}\"); }`. That gives you a table without needing a case-per-function setup, and comparing `is_err()` against a bool is enough to know whether validation caught the bad input for each named case."
+      },
+      "anti_patterns": ["is_err()"]
+    },
+    {
+      "id": "join-spawned-task",
+      "prompt": "My #[tokio::test] spawns a task with tokio::spawn and I want to wait for it to finish before asserting on the result. What's the right way?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer waits for the spawned task using its actual JoinHandle (.await on the handle returned by tokio::spawn) or a channel, before running assertions, never a fixed tokio::time::sleep/std::thread::sleep delay as a stand-in for or supplement to a real join. A select against a deadline used purely as a non-blocking safety net alongside that join -- firing only if the task hangs, never taken instead of or before the real join -- is a legitimate timeout guard, not the fixed-delay anti-pattern this scenario tests for.",
+          "pass_criteria": [
+            "Uses .await on the JoinHandle returned by tokio::spawn (or a channel send/receive) as the actual join mechanism before asserting, shown concretely.",
+            "Explains why this is reliable/deterministic compared to a fixed sleep delay (it doesn't depend on how fast the task happens to run)."
+          ],
+          "fail_criteria": [
+            "Recommends a fixed, unconditional wait before the join can be observed to have happened -- a tokio::time::sleep or std::thread::sleep taken before or instead of the join, or a backoff/polling loop that sleeps between checks -- anywhere in the wait step, whether as the sole mechanism or as extra 'insurance' alongside a real join. This does NOT include a select!'s timeout branch used only as a deadline safety net around the real join (it fires solely on a hang, and the join itself is what the assertion still actually waits on) -- do not fail an answer for that pattern alone."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Use the `JoinHandle` that `tokio::spawn` returns: `let handle = tokio::spawn(async move { ... });` and then `let result = handle.await.unwrap();` in the test, right before your assertions -- `.await`ing the handle blocks the test task until the spawned task has actually completed, regardless of how fast or slow it happens to run on a given machine or under load. That gives you the task's return value directly, so you can assert on `result` rather than on some side effect you have to guess has landed. If the spawned task communicates through a channel instead of returning a value, receiving from that channel (`rx.recv().await`) works the same way -- it blocks until the sender side actually signals. Avoid `tokio::time::sleep`/`std::thread::sleep` for this -- a fixed delay is a guess about how long the task will take, and it either wastes time when the task finishes early or flakes under CI contention when it doesn't finish in time.",
+        "known_wrong": "The simplest way is to just add `tokio::time::sleep(Duration::from_millis(100)).await` right after `tokio::spawn(...)`, then run your assertions -- that gives the task enough time to finish in almost every case without needing to hang onto the `JoinHandle` or deal with `.unwrap()`ing it. If it's occasionally still flaky in CI, bump the delay up to something like 500ms; that's usually enough headroom and is a lot less code than threading a handle or a channel through just for a test.",
+        "vague": "Wait for the spawned task properly instead of just sleeping for a bit before you check the result.",
+        "subtle_wrong": "Hold onto the handle and `.await` it: `let handle = tokio::spawn(async move { ... }); let result = handle.await.unwrap();` before asserting -- that's the reliable way to know it's finished. If you're still seeing occasional flakes in CI, throw in a short `tokio::time::sleep(Duration::from_millis(50)).await` right after the `.await` too, just as extra insurance before the assertions run."
+      },
+      "anti_patterns": ["tokio::time::sleep"]
+    }
+  ]
+}