agentleFS
alexderzalexderz/agentic-toolbox/skills/lang-c/SKILL.md

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.

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
  1. Distinctive:

    Prefer ASan + UBSan on tests.

    line 25
  2. Distinctive:

    Document who frees a returned pointer in the header comment.

    line 35
  3. Very specific:

    Prefer explicit widths (uint32_t) at ABI and file boundaries.

    line 38
  4. Distinctive:

    Check every I/O and alloc.

    line 44
  5. Distinctive:

    No data races. Shared mutable state needs a documented lock or is not shared.

    line 49
  6. Very specific:

    Every memcpy/strcpy/sprintf cousin has a bound in the diff.

    line 63
  7. Distinctive:

    No new signed/unsigned surprises in length math.

    line 65

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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-test

Prefer 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, memcpy with known n).
  • malloc / realloc / fopen results 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 once as the repo already does. Minimal includes. No using — this is C.
  • Prefer explicit widths (uint32_t) at ABI and file boundaries.

Errors

  • Return int error codes or the project's existing error type. Do not mix errno writes 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.
  • volatile is 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/sprintf cousin has a bound in the diff.
  • Ownership of every *alloc is 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. No scanf("%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 goto in a file that does not use cleanup-goto.
  • Disabling a warning instead of fixing the site.

Never

  • gets, strcpy, strcat, sprintf into a fixed buffer.
  • strncpy as a "safe strcpy" — it does not always NUL-terminate.
  • Double-free, use-after-free, returning a stack pointer.
  • Unchecked narrowing (int64_t → int / size_t surprises).
  • Mixing new/delete into a .c file.

Red flags

  • "The buffer is big enough"
  • "malloc never fails here"
  • "I'll add the size check later"
  • "It's C, sanitizers are overkill"

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.