Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add leifericf/agentic-sdk --skill write-ziggit clone --depth 1 https://github.com/leifericf/agentic-sdkWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/leifericf/agentic-sdk/write-zig)<a href="https://agentmods.dev/skills/leifericf/agentic-sdk/write-zig"><img src="https://agentmods.dev/badge/skills/leifericf/agentic-sdk/write-zig.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00037 | $0.01889 |
| Opus 5 | $0.00018 | $0.00945 |
| Sonnet 5 | $0.00007 | $0.00378 |
| Haiku 4.5 | $0.00004 | $0.00189 |
Grade A, and why
write-zig scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 149 lines — stays where its author put it; the contents beside it link to each section on GitHub.
write-zig
Write Zig for the project. The standard is
skills/write-zig/references/zig-style.md (read it first). The
architecture it implements is Functional Core / Imperative Shell; the
Zig expression of that split, the allocator-per-phase discipline, and
the native boundary contract live in
skills/shared/references/architecture.md. Placement comes from the
project's module map (the :architecture :modules entry in the
descriptor). The why behind the constraints is the ADR log: scan it
before designing against an unexplained rule.
Zig in this project means one of three things:
- A native body at a language edge. Real Zig behind a C ABI, a NIF,
or a foreign-function boundary, never a weakened DSL. The wrapper the
host language generates provides ergonomic locals; inside the body,
ordinary Zig is free: comptime, allocators, SIMD, C imports via
@cImport, packed structs. Where the body lives is the threshold rule below. - A Zig subsystem. A pure-core subsystem written in Zig (a reader, normalizer, validator, planner, or an ops module) that takes data and returns data and never threads a file handle or a writer through. The plan stays a pure value.
- Test fixtures and C interop headers when a system library is
involved.
@cImportbrings the declaration in; never translate a system header by hand.
Where the body lives
Inline bodies are for live exploration and tiny accessors (one
expression or a few lines, no C interop). Before a body lands it moves
to the module's co-located .zig when any of these hold: it links a C
library or uses @cImport, @cInclude, or @cDefine; it @imports a
resource or uses @embedFile; or it exceeds about 25 lines. One file
per module, no sibling @import splits that defeat the resource
constraint. Moving a body from inline to file is content-preserving: the
compile cache keys on the normalized Zig text, not the path, so it costs
one recompile.
Procedure
- Decide the boundary, not the internals. The signature is the
whole contract: data in, data out, opaque handles for native state
(see the native boundary contract in
skills/shared/references/architecture.md). The body works within the boundary; it never tries to reshape what crosses it. Scalars copy across; a slice handed in is valid only for the duration of the call; returned native memory is explicitly owned, copied, or wrapped in a handle whose finalizer frees it. - Zig discipline. The load-bearing rules:
- Allocator-per-phase. Parse arena, validation arena, execution
allocator, per-node scratch, output allocator. Pass
std.mem.Allocatorexplicitly as a parameter; no hidden globals. The allocator is part of the signature, not an ambient. - defer and errdefer on every path. Pair every
alloc,create, orinitwithdefer, orerrdeferwhen the value escapes only on the success path. When a helper allocates twice, write the errdefer for the first before allocating the second. Slices and pointers do not outlive their backing memory; an arena that frees at phase end frees everything it lent out. - No allocation on hot paths. A realtime callback or a per-frame
renderer allocates nothing on the steady path. Allocate buffers at
setup; the steady loop only reads source buffers and writes into
preallocated memory. A
try allocator.alloc(...)in the steady loop is a critical finding, not a style note. - Errors as values plus diagnostics. Error unions drive control
flow; user-facing failures also carry a structured diagnostic (a
serializable record with level, code, message, and, when the value
came from parsed input, its path and span). The core returns
diagnostics; it never prints. Prefer explicit named error sets on
public functions; never
anyerrorin a public API. - Guard the output for finiteness at a numeric seam. A finite input can overflow internal math to NaN or infinity; sanitizing only the input is insufficient. Check the result before it crosses the boundary and degrade a non-finite value to the documented absent datum; never let it escape.
- SIMD where it earns its place.
@Vectorand@shufflefor the inner loops. Benchmark before adopting; a realtime path cares about the 99th percentile, not the average.
- Allocator-per-phase. Parse arena, validation arena, execution
allocator, per-node scratch, output allocator. Pass
- Failure model. A malformed input is expected, not a panic.
Validate headers and sizes before the main loop; bound the work
proportional to the input size so a hostile length fails fast instead
of allocating and crashing. Untrusted input never reaches an
unreachableor an unchecked size cast. Errors cross the native edge as values, never as exceptions; an exception that crosses a NIF or a foreign-function call is a bug. - Verify like the lanes.
zig fmt --checkon changed source; the build lane (the floor); the module's tests. For any slice, pointer, handle, or allocator code, run it through a test that usesstd.testing.allocatorso a leak fails the test, and through the integration lane with both a known-good and a malformed input.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 149 lines · 37 tokens per session scan A 8385e12da71b
write-zig is a skill published in the GitHub repository leifericf/agentic-sdk (5 stars, last pushed 6d ago), licensed MIT. It adds 37 tokens to every session and 1,889 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
matlab
Build, review, migrate, and safely plan MATLAB or GNU Octave numerical workflows, including arrays, tabular/time data, tests, projects, graphics, MAT files, and explicit Python interoperability.
ast-grep
Guide for writing ast-grep rules to perform structural code search and analysis. Use when users need to search codebases using Abstract Syntax Tree (AST) patterns, find specific code structures, or perform complex code queries that go beyond simple text search. This skill should be used when users ask to search for…
platform-detection
Identify a .NET project's test platform, framework, command mode, and SDK-style vs classic project system. Use only for "which test platform/framework?", "VSTest or MTP?", or "what runner does this project use?", including bridge settings, UseVSTest opt-outs, and incompatible or conflicting VSTest/MTP configuration.…
unity-version-split
Split a C# file into Unity 6.5+ and pre-Unity 6.5 variants. Use when a file needs different implementations for different Unity versions due to API changes (e.g., EntityId vs int, GetEntityId vs GetInstanceID).
omh-rust
This is a Hermes-native rust workflow skill.
axiom-concurrency
Use when writing ANY async code, actors, threads, or seeing ANY concurrency error. Covers Swift 6 concurrency, @MainActor, Sendable, data races, async/await patterns.