Best for
- BUILD mode — generating new C/C++: follow the rules as defaults, not
- AUDIT mode — reviewing existing C/C++: hunt violations using the audit
martinholovsky/SOTA-skills/skills/sota-c-cpp/SKILL.md
State-of-the-art C and C++ engineering rules (2026 baseline) that Claude applies when writing or auditing C/C++. Covers modern idioms (RAII, value semantics, smart pointers, C++23), memory safety (lifetimes, bounds, sanitizers, hardening flags), undefined behavior, security (SEI CERT C/C++, MISRA, integer/buffer/format-string, injection), concurrency (C/C++ memory model, atomics, data races), build/tooling/CI (CMake, clang-tidy, cppcheck, ASan/UBSan/TSan, vcpkg/Conan, supply chain), and performa
Decision brief
Expert-level rules for producing and auditing production C and C++. C and C++ are memory-unsafe by default: the compiler will not stop you from reading freed memory, overrunning a buffer, or invoking undefined behavior (UB) that the optimizer then weaponizes. These rules exist t…
Compatibility matrix
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/martinholovsky/SOTA-skills --skill "skills/sota-c-cpp"Inspect the Agent Skill "sota-c-cpp" from https://github.com/martinholovsky/SOTA-skills/blob/7c8ae3e03ba5c8ec3292c581d92d458035240f4c/skills/sota-c-cpp/SKILL.md at commit 7c8ae3e03ba5c8ec3292c581d92d458035240f4c. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
Two consumers, one source of truth:
1. Before writing, read the rules files relevant to the task (see index). A parser handling untrusted bytes needs 02, 03, 04; a threaded service needs 05. 2. Apply the top-10 non-negotiables (below) unconditionally. 3. New projects: CMake (≥3.20) with -Wall -Wextra -Wpedantic -W…
Work through each relevant rules file's audit checklist against the target. Run the listed grep/clang-tidy/sanitizer commands; confirm each hit manually (greps are recall-oriented). Where feasible, build with -fsanitize=address, undefined and run the test suite — a sanitizer abo…
Review the “Severity conventions” section in the pinned source before continuing.
Group findings by severity, CRITICAL first. End with: counts per severity, the three highest-leverage fixes, and which checklists/sanitizers were run.
Permission review
No configured static risk pattern was detected
This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.
Evidence record
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 85/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 10 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Expert-level rules for producing and auditing production C and C++. C and C++
are memory-unsafe by default: the compiler will not stop you from reading
freed memory, overrunning a buffer, or invoking undefined behavior (UB) that
the optimizer then weaponizes. These rules exist to claw back the safety the
language doesn't give you — through RAII, the type system, sanitizers, hardened
build flags, and disciplined review. Baseline: C++23 (ISO/IEC 14882:2024) and
C17/C23; flag where a control needs a newer toolchain. C++26 is feature-complete
(DIS ballot 2026) — contracts, reflection, erroneous behavior for uninitialized
reads, and a standardized hardened standard library; the last is usable today
via libc++/libstdc++ hardening flags (rules/02). Every rule states the
why; every rules file ends with an audit checklist of grep/clang-tidy/
sanitizer patterns.
Two consumers, one source of truth:
02, 03, 04; a threaded service
needs 05.-Wall -Wextra -Wpedantic -Werror, the
OpenSSF hardening flags
(rules/04), a debug build wired to ASan+UBSan, clang-tidy + clang-format
configs, and CI running all of it from day one (rules/06).new/malloc/fopen/mutex.lock() should be
owned by a destructor (unique_ptr, container, lock_guard), not a manual
matching call you can forget on an early return or exception.-Wall -Wextra build is the floor, not
the goal — also run a static analyzer and the sanitizers (rules/06).reinterpret_cast,
unsafe C interop, manual lifetime), leave a // NOTE(sota): comment
explaining the invariant you're upholding so auditors don't flag it blind.Work through each relevant rules file's audit checklist against the target.
Run the listed grep/clang-tidy/sanitizer commands; confirm each hit manually
(greps are recall-oriented). Where feasible, build with -fsanitize=address, undefined and run the test suite — a sanitizer abort is ground truth.
| Severity | Meaning | Examples |
|---|---|---|
| CRITICAL | Exploitable memory corruption or guaranteed UB on reachable input | Heap/stack buffer overflow on attacker data, use-after-free, double-free, OOB write, format-string with user-controlled fmt, system() with interpolated input, data race on a pointer |
| HIGH | Likely corruption, crash, or security weakness | Unchecked malloc/new size from input, integer overflow feeding an allocation or index, missing bounds check, strcpy/sprintf/gets, TOCTOU on a path, missing RAII so a leak/UB occurs on the exception path |
| MEDIUM | Correctness/maintainability hazard, latent bug | Raw owning pointers, manual new/delete pairs, C-style casts, narrowing conversions, memcpy where a typed copy fits, missing override/= delete, signed/unsigned comparison |
| LOW | Idiom/perf debt, works but wrong shape | Pass-by-value of large objects, needless copies instead of std::move, using namespace std in headers, macros where constexpr/inline fits |
| INFO | Style/doc/hygiene | clang-format drift, naming, missing [[nodiscard]], include hygiene |
[SEVERITY] file.cpp:LINE — short title
Rule: rules/NN-name.md § section
Evidence: the offending line(s), verbatim
Impact: one sentence — what corrupts/leaks/races, under what input
Fix: concrete replacement code or action
Effort: trivial | small | medium | large
Group findings by severity, CRITICAL first. End with: counts per severity, the three highest-leverage fixes, and which checklists/sanitizers were run.
| File | Read this when... |
|---|---|
rules/01-idioms.md | Writing/reviewing any C++: RAII and the rule of zero/five, ownership with unique_ptr/shared_ptr, value semantics and move, const/constexpr, references vs pointers, casts, enum class, error handling (exceptions vs std::expected vs error codes), C-vs-C++ idiom choices |
rules/02-memory-safety.md | Anything touching pointers, buffers, lifetimes, or allocation: bounds, use-after-free/return, dangling references and views (string_view/span), iterator invalidation, ownership discipline, sanitizers (ASan/MSan), _FORTIFY_SOURCE/_GLIBCXX_ASSERTIONS |
rules/03-undefined-behavior.md | Reasoning about UB and the optimizer: integer overflow, strict aliasing, uninitialized reads, null/misaligned access, signed shifts, data races as UB, unsigned arithmetic, UBSan, why "it worked in debug" proves nothing |
rules/04-security.md | Any input crossing a trust boundary: CERT C/C++ + MISRA, banned functions (gets/strcpy/sprintf/system), integer-overflow-to-allocation, format strings, path traversal/TOCTOU, command injection, deserialization/parsers, CSPRNG, the OpenSSF hardening flag set |
rules/05-concurrency.md | Anything with threads, atomics, or shared state: the C++ memory model, data races, std::atomic and memory orders, mutex/lock_guard/scoped_lock, deadlock ordering, condition variables, std::jthread/stop tokens, TSan |
rules/06-build-tooling-ci.md | Setting up or auditing builds/CI: CMake hygiene, warning flags, clang-tidy/clang-format, static analysis (clang-analyzer, cppcheck, Coverity), sanitizer CI matrix, fuzzing (libFuzzer/OSS-Fuzz), dependencies and supply chain (vcpkg/Conan, pinning, SBOM). Test strategy lives in sota-testing; this file owns C/C++ build/test mechanics. |
rules/07-performance.md | Latency/throughput/memory work: profiling (perf, VTune, Callgrind), allocation reduction and custom allocators, move/copy elision, cache locality and data-oriented layout, <algorithm> over hand loops, LTO/PGO, micro-benchmarking pitfalls |
new/delete or
malloc/free pairs you have to match by hand; no bare owning pointers.
Use unique_ptr, containers, lock_guard/scoped_lock, RAII wrappers.
A leak or UB on the exception/early-return path is the default failure mode
of manual cleanup. (rules/01, rules/02)std::span/std::string/containers and
.at() or explicit checks, never raw pointer + length you assume. Overflow
on attacker input is CRITICAL. (rules/02)string_view, or span must not outlive its storage. Never return a
reference/view to a local or to a temporary. (rules/02)rules/03)memcpy size are
overflow-checked and the right signedness. Validate ranges before use;
prefer unsigned for sizes, check for wrap. Overflow-to-undersize-alloc is a
classic RCE primitive. (rules/03, rules/04)gets, strcpy/strcat/sprintf
(use bounded forms or std::string/std::format), no system() with
interpolated input (use posix_spawn/exec* with an argv array). (rules/04)-Wall -Wextra -Werror plus the OpenSSF
set (-D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -fstack-protector-strong -fstack-clash-protection -fcf-protection -Wl,-z,relro,-z,now). Missing
hardening on a network-facing binary is a HIGH finding. (rules/04,
rules/06)mutex/scoped_lock or use std::atomic with a justified memory
order. A -fsanitize=thread failure is not flaky noise. (rules/05)rules/06)enum class over macros,
constexpr/inline over #define, gsl::span/std::span over pointer+
length, [[nodiscard]] on must-check returns, explicit on single-arg
constructors, override/final. Make misuse fail to compile. (rules/01)Alternatives
coreyhaines31/marketingskills
When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program
alirezarezvani/claude-skills
App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist
dotnet/skills
Migrates .NET test projects from VSTest to Microsoft.Testing.Platform (MTP). Use when user asks to "migrate to MTP", "switch from VSTest", "enable Microsoft.Testing.Platform", "use MTP runner", set OutputType=Exe only for test projects in Directory.Build.props, or mentions EnableMSTestRunner, EnableNUnitRunner, or UseMicrosoftTestingPlatformRunner. USE FOR: MTP behavioral differences vs VSTest (exit code 8, zero tests discovered, --ignore-exit-code, TESTINGPLATFORM_EXITCODE_IGNORE); centralizing
JasonColapietro/suede-creator-skills
Suede-owned experimentation discipline for hypotheses, sample sizing, test duration, significance, and repeatable experiment programs. Use when comparing variants, deciding whether a result is reliable, or building an experiment backlog and cadence. NOT FOR: analytics instrumentation (use suede-analytics), post-click conversion diagnosis (use suede-site-alchemy), or writing the variant copy itself (use suede-copy).