lang-c
Skill5 starsChanged 46 days agoMITView on GitHub
use this when writing, reviewing, or testing C — *.c, *.h without C++ files in the same change. do not use for C++ (load lang-cpp) or Rust.
In this repository49 other files it gives its agents.
- AGENTS.mdAGENTS.md
- maintainers/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- buying-researcherSkill
- cursor-cloud-agents-whenSkill
- debug-anthropicSkill
- debug-pocockSkill
- debugSkill
- discover-the-ideaSkill
- docs-google-styleSkill
- golang-safetySkill
- golang-securitySkill
- golang-testingSkill
- grok-acpSkill
- host-config-pyinfraSkill
- lang-cppSkill
- lang-csharpSkill
- lang-dartSkill
- lang-dockerSkill
- lang-goSkill
- lang-javaSkill
- lang-js-tsSkill
- lang-kotlinSkill
- lang-luaSkill
- lang-makefileSkill
- lang-phpSkill
- lang-powershellSkill
- lang-protobufSkill
- lang-pythonSkill
- lang-rubySkill
- lang-rustSkill
- lang-shellSkill
- lang-sqlSkill
- lang-swiftSkill
- lang-terraformSkill
- language-routerSkill
- lang-web-markupSkill
- modern-pythonSkill
- pr-reviewSkill
- sdlc-artifactsSkill
- sdlc-onboardingSkill
- security-hardeningSkill
- shell-safetySkill
- tddSkill
- tracker-sdlcSkill
- ui-craftSkill
- ux-designSkill
- verify-before-doneSkill
- yagniSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 5 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 25
Prefer ASan + UBSan on tests.
- Distinctive: line 35
Document who frees a returned pointer in the header comment.
- Very specific: line 38
Prefer explicit widths (uint32_t) at ABI and file boundaries.
- Distinctive: line 44
Check every I/O and alloc.
- Distinctive: line 49
No data races. Shared mutable state needs a documented lock or is not shared.
- Very specific: line 63
Every memcpy/strcpy/sprintf cousin has a bound in the diff.
- Distinctive: line 65
No new signed/unsigned surprises in length math.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
C
CERT-shaped, not a CERT paste. No scripts/.
Process skills that may load with this one: language-router Load-with list.
Iron law
Every buffer has a size. Every allocation has an owner. Every return is checked.
Tooling / verify
# project flags first; do not invent a second build
cc -Wall -Wextra -Werror # when the project already errors on warnings
# tests under sanitizers when the harness exists
ASAN_OPTIONS=detect_leaks=1 ./the-testPrefer ASan + UBSan on tests. Do not claim DoD from a warning-free compile without running the test binary.
Idioms a linter misses
- Destination size is an argument to every copy/format
(
snprintf,memcpywith knownn). malloc/realloc/fopenresults are checked. One free path (goto-cleanup is fine if that is the file's style).- Initialize everything. No indeterminate reads.
- Document who frees a returned pointer in the header comment.
- Headers: include guards or
#pragma onceas the repo already does. Minimal includes. Nousing— this is C. - Prefer explicit widths (
uint32_t) at ABI and file boundaries.
Errors
- Return
interror codes or the project's existing error type. Do not mixerrnowrites with ignored returns. - Check every I/O and alloc. Partial writes are errors unless the API documents retry.
Concurrency
- No data races. Shared mutable state needs a documented lock or is not shared.
volatileis not a mutex.- Signal handlers: async-signal-safe calls only, or don't.
Testing
- Tests are real binaries or the project's harness. Assert on return codes and output, not "it compiled."
- Boundary cases: zero-length, max-length, alloc failure if you can inject it.
PR review
- Every
memcpy/strcpy/sprintfcousin has a bound in the diff. - Ownership of every
*allocis visible. - No new signed/unsigned surprises in length math.
- Public headers stay C-linkable (
extern "C"only if the project already wraps).
Security
- Integer overflow on sizes before
malloc(n * sz)— check or use a helper the project already has. - Format strings are literals. Never a user buffer as the format.
- No
gets. Noscanf("%s")without a width. - Path and command inputs are untrusted. No
system()with concat.
Always
- Size next to the pointer.
- Sanitizer-clean tests when sanitizers exist.
- A named owner for every allocation.
Ask first
- Changing signedness of a public API.
- Adding
gotoin a file that does not use cleanup-goto. - Disabling a warning instead of fixing the site.
Never
gets,strcpy,strcat,sprintfinto a fixed buffer.strncpyas a "safe strcpy" — it does not always NUL-terminate.- Double-free, use-after-free, returning a stack pointer.
- Unchecked narrowing (
int64_t→int/size_tsurprises). - Mixing
new/deleteinto a.cfile.
Red flags
- "The buffer is big enough"
- "malloc never fails here"
- "I'll add the size check later"
- "It's C, sanitizers are overkill"
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

