@h2loop/safe-c-coding-plugin 0.3.2 → 0.3.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@h2loop/safe-c-coding-plugin",
3
- "version": "0.3.2",
3
+ "version": "0.3.3",
4
4
  "description": "Safe-C coding plugin for Hydron — MISRA C:2012-aligned defensive C/C++ guidelines as an always-on skill plus a safe-c-reviewer subagent",
5
5
  "type": "module",
6
6
  "license": "UNLICENSED",
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: safe-c-coding
3
- description: ALWAYS invoke this skill before writing, generating, modifying, or reviewing any C or C++ code (.c, .h, .cpp, .hpp) no exception for one-line changes, snippets, or code that looks routine. Scope is per file, not per project or per task — do not invoke it for code in other languages (Python, JS/TS, Rust, Go, shell, build/config, etc.), even inside a project that also contains C/C++. Applies especially to embedded, automotive, medical, aerospace, or other safety-critical or resource-constrained targets where reliability, determinism, and freedom from undefined behaviour matter, but the mandatory-invocation rule applies to all C/C++ work.
3
+ description: Invoke this skill ONLY when authoring or reviewing C or C++ source — that is, when you are about to write, generate, or modify the contents of a .c/.h/.cpp/.hpp file, or when explicitly asked to review such source for defects. In those cases invocation is mandatory, with no exception for one-line changes, snippets, or code that looks routine. Do NOT invoke it for activities that merely involve an existing C/C++ project but do not change or review its source: flashing or programming a device, running or launching a binary, debugging a running program (setting breakpoints, inspecting variables, reading a stack trace, diagnosing a crash), building/compiling/linking, running tests, reading or explaining code without editing it, configuring toolchains, or working with logs, build output, or hardware. Reading a C/C++ file for context during such an activity is not authoring and does not trigger the skill. Scope is per file, not per project or per task — do not invoke it for code in other languages (Python, JS/TS, Rust, Go, shell, build/config, etc.), even inside a project that also contains C/C++. It applies especially to embedded, automotive, medical, aerospace, or other safety-critical or resource-constrained targets, but the trigger is always the act of writing or reviewing C/C++ source, never merely being near it.
4
4
  ---
5
5
 
6
6
  # Safe C Coding
@@ -11,6 +11,21 @@ A set of defensive coding guidelines for writing C (and C-style C++) that is rel
11
11
 
12
12
  **Core principle:** write the safe form by default. Avoid the language's hazardous corners (dynamic memory, undefined behaviour, implicit conversions, unbounded operations) instead of relying on review to catch them later.
13
13
 
14
+ ## When this skill applies
15
+
16
+ The trigger is the **act of authoring or reviewing C/C++ source**, not the presence of a C/C++ project. Invoke it when you are about to write, generate, or modify the contents of a `.c/.h/.cpp/.hpp` file, or when explicitly asked to review such source for defects.
17
+
18
+ Do **not** invoke it for activities that touch a C/C++ project without changing or reviewing its source:
19
+
20
+ - Flashing, programming, or provisioning a device.
21
+ - Running, launching, or deploying a binary.
22
+ - Debugging a running program — breakpoints, inspecting variables, reading a stack trace, diagnosing a crash.
23
+ - Building, compiling, or linking; running tests.
24
+ - Reading or explaining existing code without editing it.
25
+ - Configuring toolchains, or working with logs, build output, or hardware.
26
+
27
+ Reading a C/C++ file for context during any of the above is not authoring and does not trigger the skill. If, during such an activity, you decide to *edit* source to fix something, the skill applies from that point.
28
+
14
29
  > **Apply this as you write.** Whenever you write, generate, or modify C or C++ — even a one-line snippet or a quick example — follow these MISRA C:2012-aligned guidelines proactively, without waiting to be asked to review. Produce compliant code the first time; do not emit a hazardous construct now and plan to fix it later. If a guideline genuinely cannot be met, flag it and justify the deviation rather than silently violating it.
15
30
 
16
31
  ## Non-negotiables