@mrciphersmith/keryx 0.3.2 → 0.3.3

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

@@ -0,0 +1,132 @@
+---
+name: c-cpp-code-review
+description: "Use when reviewing a C or C++ change for memory-safety and undefined-behavior risks -- use-after-free, double-free, buffer overflows, dangling references, iterator invalidation, unchecked allocations, signed overflow, and unsynchronized shared state. Read-only, no edits."
+triggers:
+  - "review this C++ diff for memory safety"
+  - "check this C change for a use-after-free"
+  - "review this C++ PR for buffer overflows"
+  - "any dangling references in this C++ change"
+  - "check this diff for iterator invalidation"
+  - "review this C code for unchecked malloc"
+metadata:
+  origin: authored
+  category: review
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# C / C++ code review
+
+Read-only review of a C/C++ change for memory-safety, undefined-behavior,
+and concurrency risks specific to C/C++: use-after-free, double-free,
+buffer overflows, dangling references, iterator invalidation, unchecked
+allocations, signed overflow, and unsynchronized shared state. 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 `.c`/`.h`/`.cpp`/`.cc`/`.cxx`/`.hpp`/`.hxx` files in the
+   diff, not the whole repository.
+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
+
+**Ownership and lifetime**
+- A pointer or reference returned, stored, or captured that points into a
+  local (stack) variable, a temporary, or a since-destroyed object — flag
+  it as a use-after-free/dangling-reference risk.
+- A raw `new`/`malloc` with no traceable single owner (an RAII type, or a
+  `free`/`delete` on every exit path) — flag it; also flag a `free`/
+  `delete` that could run twice on the same pointer on different paths
+  (double-free).
+- A `malloc`/`calloc`/`realloc`/`new` result dereferenced without a
+  preceding null/exception check.
+
+**Containers and iterators**
+- An iterator, pointer, or reference into a `std::vector`/similar
+  container held across an operation that can reallocate or shift storage
+  (`push_back` past capacity, `insert`, `erase`) — flag the invalidation
+  risk.
+
+**Bounds and undefined behavior**
+- An array/buffer index or pointer-arithmetic expression built from
+  untrusted input with no visible bounds check before the read/write.
+- A signed integer addition/multiplication whose operands could plausibly
+  overflow (a size/length/offset computation from untrusted input
+  especially) — signed overflow is undefined behavior, not just "wrong
+  answer on overflow."
+- A pointer cast between incompatible types followed by a dereference (a
+  strict-aliasing violation) instead of `memcpy`/`std::bit_cast`.
+- `strcpy`/`strcat`/`sprintf`/`gets` on data whose length is not
+  statically known to fit the destination.
+
+**Concurrency**
+- A variable read from one thread while written from another with no
+  mutex/`std::atomic`/`_Atomic` guarding it — flag unsynchronized shared
+  access.
+- A manual `lock()`/`unlock()` pair instead of `std::lock_guard`/
+  `std::scoped_lock`, which skips the unlock on an early return or
+  exception thrown between them.
+
+**Interfaces**
+- A polymorphic C++ base class (deleted through a base pointer/reference
+  somewhere in the diff or its callers) with a non-virtual destructor —
+  flag as undefined behavior on delete.
+- A memory-safety or UB bug-fix diff whose test/verification step never
+  mentions running under ASan/UBSan/TSan.
+
+### Step 3: Report
+
+For each finding: file:line, the pattern, why it matters (UAF, race,
+overflow, leak), and the fix direction — but do not apply it.
+
+```
+src/parser/token_stream.cpp:88 — std::string_view into a temporary
+std::string returned from trim() outlives the temporary once trim()'s
+return value goes out of scope. Risk: use-after-free on first access.
+Fix direction: return std::string by value, or take the buffer by
+reference and return a span into the caller-owned storage.
+```
+
+## Rules
+
+- NEVER edit code — findings and fix direction only.
+- Flag use-after-free, double-free, buffer overflows, dangling
+  references, iterator invalidation, unchecked allocations, signed
+  overflow, strict-aliasing violations, and unsynchronized shared state;
+  do not report generic style nits already covered by
+  `clang-format`/`clang-tidy` (those are noise here).
+- Distinguish a finding the diff introduces from a pre-existing one in
+  code the diff merely touches.
+- When a suspected race or UB is not certain from reading alone, say "run
+  under ThreadSanitizer/UBSan to confirm" rather than asserting it exists
+  without evidence.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "The temporary's lifetime probably extends long enough in practice" | "Probably" is not a lifetime guarantee; a dangling reference into a destroyed temporary is undefined behavior the moment it is read, whether or not it happens to work today |
+| "It's just a config struct, it's only written once at startup" | If it can be written concurrently with any read (even from an init thread), it needs a guard — "only once" is a claim to verify, not assume |
+| "I'll just fix the missing NULL check 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 overflow can't realistically happen with real-world inputs" | Untrusted input is exactly the case an attacker controls; a signed-overflow bounds check exists for the input that isn't realistic in normal use |
+
+## Verification
+
+Do not report the review done until all of the following hold:
+
+- Every changed C/C++ 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/c-cpp/skills/c-cpp-code-review/evals.json

@@ -0,0 +1,73 @@
+{
+  "triggers": {
+    "positive": [
+      "I refactored Buffer::resize to use raw pointers instead of std::vector -- can you look for memory bugs before I open the PR",
+      "This PR frees the connection object on the error path -- does anything later in the function still touch it",
+      "I'm returning a reference to a local Session inside this function -- could that reference outlive the object it points to",
+      "Review this change for unsynchronized access to the shared cache",
+      "Look over this diff for iterator invalidation risk",
+      "Check whether this new parser code has any bounds issues",
+      "Review this pull request for double-free risk"
+    ],
+    "negative": [
+      "Implement this feature in modern C++, don't just review it",
+      "Fix this ctest failure in the parser module",
+      "Review this Go diff for goroutine leaks and data races",
+      "Review this Rust diff for unsafe block soundness",
+      "Write GoogleTest cases for this class",
+      "Fix this CMake linker error"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "review-iterator-invalidation",
+      "prompt": "Please review this diff:\n\n```cpp\nvoid remove_expired(std::vector<Session>& sessions) {\n  for (auto it = sessions.begin(); it != sessions.end(); ++it) {\n    if (it->expired()) {\n      sessions.erase(it);\n    }\n  }\n}\n```",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct review identifies that sessions.erase(it) invalidates `it` (and every iterator/pointer/reference from the erase point onward), so the loop's own `++it` afterward is undefined behavior, and gives a concrete fix direction -- assigning erase's return value back to `it` and skipping the increment on that branch, or using std::erase_if / the erase-remove idiom -- without applying the fix itself.",
+          "pass_criteria": [
+            "States that sessions.erase(it) invalidates the iterator `it`, and that continuing to use it (including the loop's `++it`) afterward is undefined behavior/a bug, not just a style concern.",
+            "Names a concrete fix direction: assign erase's return value back to `it` (and skip the redundant `++it` on that branch), or use std::erase_if / the erase-remove idiom.",
+            "Gives the finding with a specific location (the erase call / the loop) rather than a generic 'this loop looks risky' comment."
+          ],
+          "fail_criteria": [
+            "Says the loop is correct as written, or reviews only style/formatting without flagging the iterator invalidation."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "This has an iterator-invalidation bug: `sessions.erase(it)` invalidates `it` itself (std::vector::erase invalidates the erased element's iterator and everything after it), so the loop's own `++it` on the next iteration is undefined behavior -- it's advancing an iterator that's already been invalidated. The fix is to capture erase's return value, which is the iterator to the next valid element, and only increment in the branch that didn't erase: `if (it->expired()) { it = sessions.erase(it); } else { ++it; }`. Simpler still, since this is just filtering a vector, `std::erase_if(sessions, [](const Session& s) { return s.expired(); });` (C++20) replaces the whole loop and can't get the iterator handling wrong. Flag this as a diff-introduced correctness bug, not a style nit -- it's undefined behavior, not just inefficient.",
+        "known_wrong": "This looks fine -- the loop erases each expired session as it finds one and keeps going. std::vector::erase is a normal member function call, so once it returns the loop just continues from where `it` was pointing, same as with any other container operation in the middle of a loop.",
+        "vague": "The loop might have an issue with how it's iterating while also modifying the vector, worth taking another look at that.",
+        "subtle_wrong": "Good use of `expired()` to filter here. One nit: `sessions.erase(it)` is O(n) per call since it has to shift every following element down, so for a large sessions vector this loop is O(n^2) overall. Consider collecting the expired indices first and erasing them in a single pass afterward for better performance, but functionally the loop is correct since erase() returns a valid iterator afterward regardless of what the loop does with it."
+      }
+    },
+    {
+      "id": "review-unchecked-malloc-and-free",
+      "prompt": "Please review this diff:\n\n```c\nstruct Buffer *buffer_create(size_t size) {\n  struct Buffer *buf = malloc(sizeof(struct Buffer));\n  buf->data = malloc(size);\n  buf->size = size;\n  return buf;\n}\n```",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct review flags that neither malloc call's return value is checked for NULL before being dereferenced or stored (buf->data is written on a possibly-NULL buf, and buf->data itself is never checked), and that a failure of the second malloc leaks the first allocation with no free -- and states a fix direction (check both returns, free buf on the second failure) without applying it.",
+          "pass_criteria": [
+            "Flags that `buf` (the first malloc's result) is dereferenced (buf->data, buf->size) with no NULL check first.",
+            "Flags that `buf->data` (the second malloc's result) is also never checked for NULL before being stored/returned.",
+            "States that if the second malloc fails, the first allocation (`buf`) is never freed before the function could reasonably be considered to have failed -- a leak on that error path -- and gives a concrete fix direction (check both allocations, free buf and return NULL/an error on the second one failing)."
+          ],
+          "fail_criteria": [
+            "Reviews the diff without flagging at least the missing NULL checks on both malloc results."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Two problems here. First, neither malloc result is checked for NULL: `buf` is dereferenced immediately (`buf->data = ...`, `buf->size = ...`) with no check that the first malloc actually succeeded, and `buf->data` itself is stored and returned without ever being checked either -- a caller has no way to tell a real allocation from a failed one. Second, if the second malloc (for `buf->data`) fails, `buf` itself is already allocated and is never freed on that path -- a leak. Fix direction: check `buf` for NULL and return NULL immediately if it is; check `buf->data` for NULL and, if it failed, `free(buf)` before returning NULL so the first allocation doesn't leak on the error path.",
+        "known_wrong": "This looks like a standard constructor-style function -- allocate the struct, allocate its buffer, fill in the fields, return the pointer. malloc failures are rare enough in practice that most codebases don't bother checking every single call, and the two-allocation pattern here is pretty typical for a struct that owns a separately-sized buffer.",
+        "vague": "Might want to double check the error handling around the allocations in this function before merging.",
+        "subtle_wrong": "One issue: if `malloc(size)` for `buf->data` fails, the function still returns `buf` with `buf->data` set to NULL and `buf->size` set to the requested size, which means a caller could later try to write into `buf->data` at up to `buf->size` bytes and crash on a NULL write. The fix is to have callers check `buf->data != NULL` themselves before using it, rather than checking anything inside buffer_create -- that way the allocation and the usage-time check stay in the caller's control, and buf itself never needs a NULL check since malloc(sizeof(struct Buffer)) essentially never fails for a small fixed-size struct like this."
+      }
+    }
+  ]
+}

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

@@ -0,0 +1,151 @@
+---
+name: c-cpp-implementation
+description: "Use when implementing or extending a feature in C or modern C++ (17/20/23) -- ownership and RAII, smart pointer choice, move semantics, std::span, manual malloc/free lifetime in C, and choosing safe standard-library APIs over unsafe ones. Not for Rust, Go, or another systems language (use that language's own implementation skill)."
+triggers:
+  - "implement this feature in modern C++"
+  - "add a function to this C module"
+  - "which smart pointer should own this object"
+  - "convert this raw new/delete to RAII"
+  - "add a std::span-based API for this buffer"
+  - "write the malloc/free lifetime for this C struct"
+metadata:
+  origin: authored
+  category: implement
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# C / C++ implementation (C++17/20/23, C99/C11+)
+
+Implement or extend a feature in a C or C++ codebase: ownership design,
+resource lifetime, memory safety, and modern idiom for whichever of the
+two languages the file under change actually is. Scoped to C/C++
+specifically — `rules/coding-style.mdc`, `rules/patterns.mdc`, and
+`rules/security.mdc` carry the full stack-specific rule set this skill's
+checklist is built from; read them before writing code, not just this
+summary.
+
+## Workflow
+
+### Step 1: Discover the project's own conventions
+
+1. Identify the build system (`CMakeLists.txt`, `Makefile`, `meson.build`)
+   and the C/C++ standard it targets (`CMAKE_CXX_STANDARD`, `-std=`
+   flags) — do not use a language feature (`std::span`, `constexpr` on a
+   function that needs C++20, a C11-only `_Generic`) the project's own
+   declared standard predates.
+2. Determine whether the file under change is C or C++ from its
+   extension (`.c`/`.h` vs `.cpp`/`.cc`/`.cxx`/`.hpp`/`.hxx`) and match
+   that language's idiom — do not introduce C++-only constructs
+   (`std::unique_ptr`, exceptions, namespaces) into a `.c` file.
+3. Read 1-2 neighboring files for: existing ownership style (smart
+   pointers vs. manual `malloc`/`free`), whether the project has a
+   `.clang-format`/`.clang-tidy` config, existing error-handling
+   convention (exceptions, error codes, `std::expected`), and whether a
+   testing framework (GoogleTest, Catch2) is already wired into the
+   build.
+
+### Step 2: Design ownership before writing
+
+- For every new heap allocation, decide who owns it and for how long
+  *before* writing the allocation: a `std::unique_ptr` (single owner,
+  the default), a `std::shared_ptr` (only when ownership is genuinely
+  shared across objects with independent lifetimes), a stack/automatic
+  object (when it never needs to outlive its scope), or — in C — a
+  `malloc`/`free` pair with an explicit, documented ownership contract in
+  the header comment.
+- Trace every pointer/reference this change returns or stores: does it
+  outlive the object it points into? A pointer or reference into a local
+  variable, a temporary, or a container element that might reallocate is
+  a use-after-free or dangling-reference bug the moment it escapes.
+- For concurrent access, decide up front which mutex (or `std::atomic`)
+  guards which shared variable — do not add a shared variable first and
+  retrofit synchronization after a race shows up.
+
+### Step 3: Implement
+
+1. C++: prefer RAII types (smart pointers, `std::lock_guard`,
+   `std::vector`/`std::string`) over manual acquire/release; use
+   `std::make_unique`/`std::make_shared`, not a bare `new` handed to a
+   smart pointer constructor.
+2. C: check every `malloc`/`calloc`/`realloc` return for `NULL`; release
+   every acquired resource on every exit path (a `goto cleanup;` pattern
+   for functions with more than one early return keeps this from being
+   duplicated and missed).
+3. Use `std::span` (C++20+) for a non-owning view over a buffer instead
+   of a raw `(pointer, length)` pair when the project's standard allows
+   it; validate every index/length derived from untrusted input before
+   it reaches a read or write.
+4. Move rather than copy when transferring ownership (`std::move` into a
+   by-value parameter, or an rvalue-ref overload) for anything
+   non-trivially-copyable.
+5. Use a named cast (`static_cast`/`const_cast`/`reinterpret_cast`) in
+   C++, never a C-style cast — it states which conversion is actually
+   intended.
+6. Format with the project's configured `clang-format` as you go, not as
+   an afterthought.
+
+### Step 4: Verify
+
+```bash
+cmake --build build   # or the project's own configured build command
+ctest --test-dir build --output-on-failure
+```
+
+For anything touching manual memory management, buffers, pointer
+arithmetic, or concurrency, also build and run under sanitizers before
+reporting done:
+
+```bash
+cmake -S . -B build-asan -DCMAKE_BUILD_TYPE=Debug \
+  -DCMAKE_CXX_FLAGS='-fsanitize=address,undefined -fno-omit-frame-pointer -g'
+cmake --build build-asan && ctest --test-dir build-asan --output-on-failure
+```
+
+A build/test/sanitizer failure at this step is a signal to fix the
+implementation, not to reach for `c-cpp-build-fix`'s scope unless the
+failure is a build/toolchain/link problem unrelated to the feature logic.
+
+### Step 5: Report
+
+```
+Implemented: src/parser/token_stream.cpp, include/parser/token_stream.hpp
+  - std::unique_ptr-owned TokenStream, std::span<const char> input view
+  - build + ctest + ASan/UBSan build all pass
+```
+
+## Rules
+
+- Never write a raw `new`/`malloc` whose matching `delete`/`free` is not
+  either in the same RAII destructor or on every exit path of the
+  function that allocated it.
+- Never return, store, or capture a pointer/reference to a local
+  (stack-lifetime) variable, or to a temporary's member.
+- Never dereference a `malloc`/`new` result without first checking it for
+  `NULL`/an exception path.
+- Match the project's declared C/C++ standard — do not use a language or
+  library feature newer than what the build configuration targets.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll use `shared_ptr` here so I don't have to think about who owns it" | `shared_ptr` is not a substitute for an ownership decision — reaching for it by default hides a real single-owner relationship behind atomic refcounting and can create reference cycles a `unique_ptr` design would have made obvious |
+| "This buffer's length is always correct in practice, I won't re-check it" | "In practice" is not a proof; an unchecked length from untrusted input is exactly how a buffer overflow gets in |
+| "I'll return a pointer to this local struct, the caller will use it right away" | "Right away" still means after the function returns, by which point the stack frame is gone; the pointer is already dangling at the call site |
+| "malloc can't really fail here, I'll skip the NULL check" | A failed allocation dereferenced as non-NULL is a guaranteed crash or corruption the moment it does happen; the check costs one branch |
+
+## Verification
+
+Do not report the work done until all of the following hold:
+
+- The project's configured build and test commands exit 0.
+- For any change touching manual memory management, buffers, or
+  concurrency: an ASan+UBSan (and, for threaded code, TSan) build of the
+  touched tests also passes clean.
+- Every new heap allocation has a traceable single owner (an RAII type,
+  or a documented `malloc`/`free` contract) — no bare `new`/`malloc` with
+  no visible release path.
+- No pointer or reference returned or stored by the change outlives the
+  object it refers to.

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

@@ -0,0 +1,74 @@
+{
+  "triggers": {
+    "positive": [
+      "Implement a new Logger class that owns a single output file handle for its lifetime",
+      "Add a function that hands back a parsed config object to the caller",
+      "Write the ownership logic for this heap-allocated audio buffer",
+      "Implement a factory function that constructs and returns this object",
+      "Add a getter that returns a view into this struct's internal array",
+      "I need to add a resource-owning class to this module, how should it manage its handle",
+      "Add a new TokenStream that wraps a buffer passed in at construction"
+    ],
+    "negative": [
+      "Implement this feature in Rust using ownership and borrowing",
+      "Implement this feature in Go using a worker pool and errgroup",
+      "Write a unit test for this C++ class",
+      "Review this C++ diff for memory safety issues",
+      "Fix this failing ctest run for the parser module",
+      "Add table-driven tests for this Python function"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "ownership-unique-vs-shared",
+      "prompt": "I'm adding a new Logger class that owns a single output file handle for its lifetime, and only one part of the program ever creates or holds it. What smart pointer should manage the file handle, and how should the class be structured?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer recommends single, exclusive ownership for the file handle -- either std::unique_ptr<std::ofstream>, or holding a plain std::ofstream member directly by value (std::ofstream is itself move-only RAII, so no pointer indirection is required at all for a single owner) -- explains concretely why std::shared_ptr is the wrong choice here (unnecessary atomic refcount overhead and it obscures the fact that there is exactly one owner), and, if it chooses unique_ptr, shows constructing it with std::make_unique rather than a bare new.",
+          "pass_criteria": [
+            "Recommends either std::unique_ptr specifically or a plain by-value std::ofstream member (not just 'a smart pointer', and not std::shared_ptr) for the file handle.",
+            "Gives a concrete reason std::shared_ptr is inappropriate for this single-owner case -- refcount overhead, or that it hides/misrepresents a single-owner relationship -- not just 'keep it simple'.",
+            "If it recommends std::unique_ptr, shows concrete construction, e.g. std::make_unique, rather than a bare new handed to the pointer; a by-value std::ofstream member satisfies this criterion by needing no pointer construction at all."
+          ],
+          "fail_criteria": [
+            "Recommends std::shared_ptr as the way to manage the file handle for this single-owner case instead of std::unique_ptr. Mentioning std::shared_ptr only to explain why it is the wrong choice here is not a failure."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Since exactly one part of the program creates and holds the Logger's file handle, the simplest correct option is to hold std::ofstream directly as a plain by-value member -- std::ofstream is already move-only RAII, so it needs no pointer wrapper at all: `std::ofstream file_;`, opened in the constructor's initializer list or body. If the handle weren't already an RAII type, or you specifically needed heap allocation (e.g. a pimpl or a polymorphic handle), std::unique_ptr<std::ofstream> constructed with std::make_unique<std::ofstream>(path) is the equivalent single-owner choice. Either way, don't reach for std::shared_ptr here -- there's only one owner, so shared_ptr's atomic reference counting is pure overhead, and using it anyway would misrepresent the ownership model to anyone reading the class later, making them think the handle might be shared when it never is. Make Logger non-copyable (delete the copy constructor/assignment, or let it default from the ofstream/unique_ptr member already being move-only) so the compiler enforces the single-owner invariant instead of relying on convention. The destructor needs no explicit code -- the member's own destructor closes the file when the Logger is destroyed.",
+        "known_wrong": "Just use std::shared_ptr<std::ofstream> for the member -- it's the safer default for any owned resource since you don't have to think hard about whether ownership might need to become shared later, and the reference counting overhead is negligible in practice. Construct it with std::make_shared<std::ofstream>(path) and you're done; if another part of the code ever needs access to the same handle down the road, shared_ptr already supports that with no further changes.",
+        "vague": "Use a smart pointer to manage the file handle so it cleans up automatically instead of managing it by hand.",
+        "subtle_wrong": "std::unique_ptr would work, but since Logger might eventually get passed into a callback stored in a std::function elsewhere in the codebase, go with std::shared_ptr<std::ofstream> from the start -- unique_ptr can be awkward to move into callback storage, and shared_ptr sidesteps that friction entirely while still being reference-counted-safe if the Logger is ever captured by more than one closure."
+      },
+      "anti_patterns": ["std::shared_ptr"]
+    },
+    {
+      "id": "dangling-view-into-local",
+      "prompt": "I want to add a helper that trims leading/trailing whitespace from a string for the caller to use right away. Here's my sketch:\n\n```cpp\nstd::string_view trim(const std::string& input) {\n  std::string result = strip_ws(input);\n  return result;\n}\n```\n\nDoes this look right?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies that `result` is a local std::string destroyed when trim() returns, so the returned std::string_view refers to freed/destroyed storage -- a dangling view whose use is undefined behavior, not merely risky -- and proposes a concrete fix such as returning std::string by value instead of a view, or having the caller supply the backing storage so a view into it stays valid.",
+          "pass_criteria": [
+            "States that `result` is a local variable destroyed at the end of trim(), so the returned string_view is left referring to destroyed/deallocated storage.",
+            "States or implies this is undefined behavior (or otherwise unsafe to use) on the very first access by the caller, not just 'risky' or 'not ideal'.",
+            "Proposes a concrete fix: return std::string by value (relying on move/RVO), or restructure so the view points into storage the caller owns and that outlives the call."
+          ],
+          "fail_criteria": [
+            "Says the code is fine as long as the caller uses the returned string_view immediately after the call, or otherwise treats prompt use as making the dangling view safe."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "This has a dangling-reference bug: `result` is a std::string local to trim(), and it's destroyed the moment the function returns. The std::string_view you're handing back still points at wherever result's buffer was, which is now freed -- reading through it on the caller's side is undefined behavior, not just fragile, and it doesn't matter that the caller intends to use it 'right away'; the string's destructor has already run by the time the caller gets the return value. The fix is to return std::string by value instead of a view -- `std::string trim(const std::string& input) { return strip_ws(input); }` -- and let move semantics/RVO make that cheap. If you specifically need a non-owning view into existing storage (to avoid a copy), the caller has to own the buffer and pass it in so the view you return points into memory that outlives the call, rather than into something trim() allocated and destroyed itself.",
+        "known_wrong": "That looks fine -- as long as the caller assigns the returned string_view to a variable and uses it right away, before anything else runs, the underlying characters are still going to be sitting in memory. string_view is a lightweight, non-owning view specifically so you avoid an extra string copy on the return path, so this is actually the more efficient version of the function compared to returning a std::string by value.",
+        "vague": "Something about the lifetime of the string here seems off, you might want to double check how long the data returned actually lives.",
+        "subtle_wrong": "The one thing to watch here is that `result` is constructed by value inside the function, so returning a view of it does incur a hidden copy of the underlying buffer before the view is handed back -- that's a performance concern more than a correctness one. If you want to avoid that copy, mark `result` as `static thread_local` inside trim() so its storage persists across calls instead of being destroyed on return; that keeps the string_view you return valid indefinitely without needing to change the function's return type."
+      }
+    }
+  ]
+}

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

@@ -0,0 +1,152 @@
+---
+name: c-cpp-testing
+description: "Use when a C or C++ test suite needs writing, extending, or fixing -- GoogleTest TEST/TEST_F/TEST_P, death tests, fixture setup/teardown, and verifying a memory-safety or concurrency fix under AddressSanitizer/UndefinedBehaviorSanitizer/ThreadSanitizer. Not for another systems language's own test tooling, such as Rust's cargo test (use that language's own testing skill)."
+triggers:
+  - "write GoogleTest cases for this C++ class"
+  - "add a TEST_F fixture for this component"
+  - "fix this failing ctest"
+  - "add a death test for this assertion"
+  - "verify this fix under AddressSanitizer"
+  - "add a parameterized test with TEST_P"
+metadata:
+  origin: authored
+  category: test
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# C / C++ testing (GoogleTest, sanitizers)
+
+Write, extend, or fix a C/C++ test suite: GoogleTest cases and fixtures,
+death tests, parameterized tests, and sanitizer-backed verification for
+memory-safety and concurrency fixes. `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. Find the test tree (`tests/`, `test/`, or `*_test.cpp` beside the
+   source) and the test framework already wired into the build
+   (GoogleTest is assumed unless the project's `CMakeLists.txt`/build
+   files show Catch2 or another framework — match whichever is there).
+2. Read 1-2 neighboring test files for: fixture naming, assertion style
+   (`ASSERT_*` vs `EXPECT_*` usage pattern), whether mocks
+   (`gmock`) are already in use, and whether sanitizer builds are already
+   configured as a separate CMake preset/target.
+3. Check whether the project's CI or build scripts already run an ASan/
+   UBSan/TSan build — reuse that configuration rather than inventing a
+   new one.
+
+### Step 2: Plan test cases
+
+**Functions:** happy path, edge cases (empty/zero/null inputs, boundary
+values), error cases (an exception thrown, an error code returned, or —
+for a hard invariant — a process-terminating `CHECK`/`assert`).
+
+**Fixtures:** `TEST_F` with a fixture class deriving from
+`::testing::Test`, shared setup in `SetUp()`/teardown in `TearDown()`,
+not the constructor/destructor, when setup can fail in a way the test
+should assert on.
+
+**Parameterized:** `TEST_P` + `INSTANTIATE_TEST_SUITE_P` for the same
+case body run across a range of inputs, instead of copy-pasted `TEST`s
+with different literals.
+
+**Memory-safety/UB fixes:** a regression test that reproduces the bug
+(use-after-free, buffer overflow, signed overflow, data race) under the
+relevant sanitizer before the fix, and passes clean under that same
+sanitizer after it.
+
+**Concurrent code:** a test that starts threads under test joins them
+(`std::thread::join`, a future, a condition variable) before asserting —
+never `sleep`-synchronized — and the whole suite runs at least once under
+ThreadSanitizer.
+
+### Step 3: Write
+
+1. Create/extend the test file at the project's own convention path.
+2. Name suites/cases for the behavior under test (`ParsesEmptyInput`,
+   not `Test1`).
+3. Use `ASSERT_*` when a failure means the rest of the test cannot
+   meaningfully continue (a null result every later line dereferences);
+   `EXPECT_*` otherwise, so later checks still report.
+4. For a death test, set the death test style explicitly
+   (`GTEST_FLAG_SET(death_test_style, "threadsafe")`) when the binary is
+   multi-threaded — the default `fast` style can misbehave forking a
+   process with more than one live thread.
+5. Release any resource a fixture owns (temp files, mock servers,
+   threads) in `TearDown()`, not just at the end of a passing test body.
+
+### Step 4: Run and fix
+
+```bash
+ctest --test-dir build --output-on-failure
+```
+
+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: Sanitizer verification (when relevant)
+
+For any test covering manual memory management, buffers, pointer
+arithmetic, or shared concurrent state, also run:
+
+```bash
+cmake -S . -B build-asan -DCMAKE_BUILD_TYPE=Debug \
+  -DCMAKE_CXX_FLAGS='-fsanitize=address,undefined -fno-omit-frame-pointer -g'
+cmake --build build-asan && ctest --test-dir build-asan --output-on-failure
+
+cmake -S . -B build-tsan -DCMAKE_BUILD_TYPE=Debug \
+  -DCMAKE_CXX_FLAGS='-fsanitize=thread -fno-omit-frame-pointer -g'
+cmake --build build-tsan && ctest --test-dir build-tsan --output-on-failure
+```
+
+ASan/UBSan and TSan are separate runtimes and must not be linked into the
+same binary — build them as distinct configurations.
+
+### Step 6: Report
+
+```
+Generated: tests/token_stream_test.cpp
+  - 9 cases (3 TEST_F, 2 TEST_P instances), ctest all passing
+  - Regression case for the reported use-after-free passes clean under ASan
+```
+
+## Rules
+
+- ALWAYS match the project's existing framework, fixture, and assertion
+  conventions found in Step 1, not a different project's style.
+- NEVER modify source code under test — only test files (and fixtures/
+  mocks/testdata).
+- NEVER synchronize a concurrent test with `sleep`/`usleep`/
+  `std::this_thread::sleep_for`; join the thread or wait on a
+  condition variable/future instead.
+- Run the relevant sanitizer(s) before reporting a memory-safety,
+  UB, or concurrency fix verified.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll add a short `sleep_for(100ms)` so the worker thread finishes" | Non-deterministic under load; join the thread or wait on a condition variable so the test cannot flake |
+| "The fix looks right by inspection, I don't need to run ASan again" | Memory-safety and UB bugs are exactly the class of defect that "looks right" while still being wrong; sanitizer re-verification is the actual check |
+| "This test keeps failing; I'll change EXPECT_EQ to EXPECT_NE so it's easier to satisfy" | Weakening the assertion covers nothing about *what* the correct behavior is; find out why the actual value differs from what's expected |
+| "It's just a background thread, TSan is overkill for one test" | A single unguarded shared access is enough to be a data race; TSan is the tool built to catch exactly that at low cost |
+
+## 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
+  fixture/assertion style read in Step 1.
+- `ctest --test-dir build --output-on-failure` exits 0 with every
+  generated test passing.
+- For a memory-safety, UB, or concurrency fix: the regression test also
+  passes under the relevant sanitizer build (ASan+UBSan, or TSan for a
+  race).
+- Every thread started by a test is joined before its assertions run; no
+  test synchronizes with `sleep`.