ds-zig-review
Skill20 starsChanged 46 days agoMITView on GitHub
Review Zig code with Tiger Style constraints and Zig idioms.
In this repository52 other files it gives its agents.
- ds-dev-skill-benchSkill
- ds-agent-reviewSkill
- ds-architecture-planSkill
- ds-arenaSkill
- ds-blast-radiusSkill
- ds-blueprintSkill
- ds-bug-reviewSkill
- ds-clarity-reviewSkill
- ds-code-quality-reviewSkill
- ds-comment-reviewSkill
- ds-data-modeSkill
- ds-data-reviewSkill
- ds-debugSkill
- ds-deslopSkill
- ds-doc-quality-reviewSkill
- ds-exploreSkill
- ds-git-modeSkill
- ds-go-reviewSkill
- ds-grill-meSkill
- ds-handoffSkill
- ds-howSkill
- ds-humanizeSkill
- ds-interaction-modeSkill
- ds-java-reviewSkill
- ds-notebook-reviewSkill
- ds-onboardingSkill
- ds-osvSkill
- ds-perf-planSkill
- ds-project-checkpointSkill
- ds-project-resumeSkill
- ds-python-reviewSkill
- ds-quality-gateSkill
- ds-reflectSkill
- ds-retroSkill
- ds-roadmapSkill
- ds-rust-reviewSkill
- ds-security-reviewSkill
- ds-semgrepSkill
- ds-shell-reviewSkill
- dsSkill
- ds-specSkill
- ds-step-modeSkill
- ds-tdd-modeSkill
- ds-test-modeSkill
- ds-test-quality-reviewSkill
- ds-tiger-style-modeSkill
- ds-tldtSkill
- ds-ts-reviewSkill
- ds-ui-modeSkill
- ds-ui-quality-reviewSkill
- ds-verify-thisSkill
- ds-zoom-outSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 30
Run these, report what they surface, then do the manual review below.
- Very specific: line 34
Use the checklist as a lens, not a scorecard: reason about the actual change, report real violations anchored to file:line, and flag issues …
≈ “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
Applies to: Zig 0.16 (current stable). Systems programming, CLIs, embedded.
Zig is Tiger Style's native context (TigerBeetle): explicit allocators, no hidden control flow, and no hidden allocations map almost one-to-one onto the Tiger Style constraints. Lean into that section harder than for other languages.
Arguments
Scan the invocation for the --no-tiger, --fix, and --full flags. Treat every other argument as review scope (files or directories); if no scope is given, review the changed files on the current branch.
--no-tigerpresent → skip the Tiger Style section; run Memory & Allocators, Error Handling, Zig Idioms, Safety, and Testing only.--no-tigerabsent → run all sections (default).--fix→ after reporting, apply only the violations whose fix is mechanical and unambiguous (a rename to the idiom, a missing error check the review is certain about). Anything that changes logic or rests on an unverified assumption — especially security and correctness findings — stays report-only. After applying, re-run any build/test/lint check already in the loop and revert any fix that breaks it — or that touched more than the intended mechanical edit. End with a summary of what was applied and what was left.--full→ review the entire codebase instead of just the branch's changes. Explicit positional scope still wins;--fullonly replaces the no-scope default.
Example: /ds-zig-review --no-tiger src/ reviews src/ without Tiger Style.
Automated Checks (run first if tools are available)
zig fmt --check . # formatting drift
zig build test # tests + std.testing.allocator leak detection
zig build -Doptimize=ReleaseSafe # compile + safety-check validationRun these, report what they surface, then do the manual review below. They are baseline context — anchor findings to the code in scope; don't report pre-existing failures outside the change as if it introduced them.
Review Checklist
Use the checklist as a lens, not a scorecard: reason about the actual change, report real violations anchored to file:line, and flag issues even when they aren't listed. Don't manufacture findings to fill a category. Report only violations — no praise, no summary.
Tiger Style
Skip this section entirely if --no-tiger was passed. Otherwise it is mandatory.
- Non-trivial functions assert preconditions, postconditions, and key invariants with
std.debug.assert— assert the "can't happen" cases and on both sides of a boundary; don't demand assertions in trivial accessors - All loops over external input have explicit upper bounds; no unbounded recursion without provable termination
- Named constants for every limit, size, and capacity — no unexplained magic numbers
- Functions under 70 lines
- Errors handled or propagated explicitly — never silently dropped
Memory & Allocators
- Every allocating function takes an
std.mem.Allocatorexplicitly — no hidden global/default allocator - Each allocation paired with
defer/errdeferfor release in the same scope; no leak on the error path - Arena (
ArenaAllocator) used for batch/request-scoped lifetimes instead of scattered individual frees - Slices (
[]T, bounds-checked) preferred over many-item pointers;[]const Tfor read-only views - No use-after-free: freed memory not retained or returned; ownership of returned allocations is clear
Error Handling
- Errors returned as error unions (
!T) with explicit error sets, not encoded in sentinels or out-params - Propagated with
try; cleanup on the error path viaerrdefer - No
catch unreachableunless the impossibility is provable (and asserted); no swallowed errors via emptycatch - No
unreachableor.?on values derived from input — only where an invariant guarantees presence
Zig Idioms
comptimefor generics/compile-time computation rather than runtime reflection workarounds- Closed alternatives modeled as a tagged union (
union(enum)) with an exhaustiveswitch— no catch-allelsewhere the compiler should force handling of new variants - Optionals (
?T) unwrapped withorelse/if (x) |v|, not a blind.? - No hidden control flow introduced — no reliance on implicit conversions; narrowing casts made visible (
@intCast,@truncate) - Integer overflow intent explicit:
+%/+|only where wrap/saturate is wanted, plain+/-/*otherwise defer/errdeferdeclared next to the acquisition they release- Blocking system access (filesystem, net, timers) goes through the injected
std.Iointerface (0.16) — passed explicitly like the allocator, not reached for globally; directstd.posixcalls are largely gone - New buffered
Writer/Reader(0.16) get an explicit buffer and are flushed deliberately; a pointer to the writer is passed downstream, never a copy
Performance
Idiom-level checks only — for a ranked, costed optimization plan, use /ds-perf-plan.
- No allocation in hot paths — reuse a buffer or an arena instead of per-iteration alloc/free
- Known-size collections sized up front (
ensureTotalCapacity/initCapacity), not grown incrementally ReleaseSafecost measured before reaching forReleaseFast— drop safety checks only when justified
Safety
- Code intended for production runs in
Debug/ReleaseSafe; anyReleaseFast/ReleaseSmallchoice that drops safety checks is deliberate and justified - All external/untrusted input validated and bounded (lengths, indices, sizes) before use
- No out-of-bounds risk: slice indices and lengths checked; no raw pointer arithmetic without an asserted bound
- No command/shell execution or filesystem path built from unsanitized input; no hardcoded secrets
Testing
test "..."blocks cover the public surface and error paths — flag notable gaps, not every trivial accessor- Tests use
std.testing.allocatorso leaks fail the test - Error paths exercised with
expectError, not just the happy path - No real network/filesystem in unit tests — injected fakes;
std.testing.tmpDironly where a real FS is unavoidable
Output Format
<file>:<line>: <severity>: <problem>. <fix>.Severity levels: critical (memory safety / correctness), major (reliability / leak), minor (idiom/style).
Skip formatting nits unless they affect correctness or readability significantly.
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.

