agentleFS
Sign inStart free
MesteriisMesteriis/Engineering-Bible-AI/skills/c-cpp/SKILL.md

c-cpp

Skill0 starsChanged 4 months agoMITView on GitHub

Applies C/C++ rules for resource safety, ownership, ABI, builds, tests, and validation.

We split this skill into the rules it gives an agent

21 rules. About 0 are common, 21 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈21

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before changing C/C++ code, inspect relevant files when present:

    line 14
  2. Distinctive:

    Do not assume language standard or ABI expectations.

    line 35
  3. Distinctive:

    Keep headers minimal and stable.

    line 42
  4. Distinctive:

    Avoid unnecessary dynamic allocation.

    line 43
  5. Distinctive:

    Avoid global mutable state.

    line 44
  6. Distinctive:

    Prefer small translation units with cohesive responsibility.

    line 45
  7. Distinctive:

    Do not create giant headers full of unrelated code.

    line 46
  8. Distinctive:

    Avoid raw owning pointers.

    line 51
  9. Distinctive:

    Prefer value semantics when appropriate.

    line 53
  10. Distinctive:

    Use smart pointers only when ownership requires them.

    line 54
  11. Distinctive:

    Avoid inheritance unless polymorphism is real.

    line 55
  12. Distinctive:

    Prefer composition over inheritance.

    line 56
  13. Distinctive:

    Avoid exceptions if the project forbids them.

    line 57
  14. Distinctive:

    Do not use modern features unsupported by configured standard.

    line 58
  15. Distinctive:

    Check allocation and I/O failures.

    line 63
  16. Distinctive:

    Keep error paths correct.

    line 66
  17. Distinctive:

    Do not hide resource ownership in vague helper functions.

    line 67
  18. Distinctive:

    When code may run on constrained hardware:

    line 71
  19. Distinctive:

    avoid blocking critical loops.

    line 73
  20. Distinctive:

    avoid unsafe boot states;

    line 77
  21. Distinctive:

    Use existing build/test system.

    line 84

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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

Skill: c-cpp

Purpose

Apply the shared engineering style to C and C++ projects while respecting safety, ABI, build configuration, resource ownership, and platform constraints.

Inspect First

Before changing C/C++ code, inspect relevant files when present:

  • CMakeLists.txt
  • Makefile
  • build scripts
  • compiler flags
  • toolchain files
  • compile_commands.json
  • formatter/linter config
  • existing headers/source/tests
  • target platform constraints

Infer:

  • C/C++ standard;
  • compiler/toolchain;
  • warning policy;
  • memory ownership style;
  • test framework;
  • embedded constraints if relevant.

Do not assume language standard or ABI expectations.

General Rules

  • Preserve ABI when relevant.
  • Avoid undefined behavior.
  • Keep ownership explicit.
  • Keep headers minimal and stable.
  • Avoid unnecessary dynamic allocation.
  • Avoid global mutable state.
  • Prefer small translation units with cohesive responsibility.
  • Do not create giant headers full of unrelated code.

C++ Rules

  • Prefer RAII.
  • Avoid raw owning pointers.
  • Use const correctly.
  • Prefer value semantics when appropriate.
  • Use smart pointers only when ownership requires them.
  • Avoid inheritance unless polymorphism is real.
  • Prefer composition over inheritance.
  • Avoid exceptions if the project forbids them; otherwise follow project convention.
  • Do not use modern features unsupported by configured standard.

C Rules

  • Make ownership and lifetime explicit in names/docs.
  • Check allocation and I/O failures.
  • Avoid buffer overflows.
  • Prefer bounded operations.
  • Keep error paths correct.
  • Do not hide resource ownership in vague helper functions.

Embedded / Firmware Awareness

When code may run on constrained hardware:

  • avoid blocking critical loops;
  • avoid unbounded allocation;
  • consider stack usage;
  • consider ISR constraints;
  • avoid unsafe boot states;
  • preserve watchdog behavior;
  • be careful with volatile/hardware registers;
  • isolate platform-specific code.

Tests and Validation

Use existing build/test system.

Common commands, only when configured or clearly available:

cmake --build <build-dir>
ctest --test-dir <build-dir>
make
make test
ninja

Report exact commands and results.

Shared Cross-Ecosystem Style

Apply the shared engineering style from:

  • ../../engineering/05_design_principles.md
  • ../../engineering/06_responsibility_model.md
  • ../../engineering/07_complexity_budget.md
  • ../../engineering/12_naming_bible.md

Language-specific idioms control syntax and ecosystem details, but they must not weaken the core rules: small cohesive units, explicit boundaries, honest validation, no dumping grounds, and no fake placeholders.

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.

Check your setup, free