with one click
ds-zig-review
Review Zig code with Tiger Style constraints and Zig idioms.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
Review Zig code with Tiger Style constraints and Zig idioms.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Design a target architecture for a new system — module boundaries, dependency rules, seams, and build order — from its requirements. Reports a blueprint; changes nothing.
Analyze an existing codebase's architecture and produce a sequenced refactoring plan — assess module boundaries, dependency structure, and layering, then lay out ordered, risk-tagged steps. Language-agnostic. Reports a plan; changes nothing.
Turn a goal or another command's output into an ordered task roadmap.
Find the root cause of a failure with the scientific method — reproduce, isolate, fix, then prove it.
Interview the user relentlessly about a plan or design until reaching shared understanding.
Run an extremely strict maintainability + single-source-of-truth review of code changes — abstraction quality, file sprawl, spaghetti-condition growth, and duplicate/competing implementations. Reports findings by default; `--fix` applies the mechanical, unambiguous ones — structural/code-judo restructurings rest on judgment and stay reported.
| name | ds-zig-review |
| description | Review Zig code with Tiger Style constraints and Zig idioms. |
| disable-model-invocation | true |
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.
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-tiger present → skip the Tiger Style section; run Memory & Allocators, Error Handling, Zig Idioms, Safety, and Testing only.--no-tiger absent → 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; --full only replaces the no-scope default.Example: /ds-zig-review --no-tiger src/ reviews src/ without Tiger Style.
zig fmt --check . # formatting drift
zig build test # tests + std.testing.allocator leak detection
zig build -Doptimize=ReleaseSafe # compile + safety-check validation
Run 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.
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.
Skip this section entirely if --no-tiger was passed. Otherwise it is mandatory.
std.debug.assert — assert the "can't happen" cases and on both sides of a boundary; don't demand assertions in trivial accessorsstd.mem.Allocator explicitly — no hidden global/default allocatordefer/errdefer for release in the same scope; no leak on the error pathArenaAllocator) used for batch/request-scoped lifetimes instead of scattered individual frees[]T, bounds-checked) preferred over many-item pointers; []const T for read-only views!T) with explicit error sets, not encoded in sentinels or out-paramstry; cleanup on the error path via errdefercatch unreachable unless the impossibility is provable (and asserted); no swallowed errors via empty catchunreachable or .? on values derived from input — only where an invariant guarantees presencecomptime for generics/compile-time computation rather than runtime reflection workaroundsunion(enum)) with an exhaustive switch — no catch-all else where the compiler should force handling of new variants?T) unwrapped with orelse / if (x) |v|, not a blind .?@intCast, @truncate)+%/+| only where wrap/saturate is wanted, plain +/-/* otherwisedefer/errdefer declared next to the acquisition they releasestd.Io interface (0.16) — passed explicitly like the allocator, not reached for globally; direct std.posix calls are largely goneWriter/Reader (0.16) get an explicit buffer and are flushed deliberately; a pointer to the writer is passed downstream, never a copyIdiom-level checks only — for a ranked, costed optimization plan, use /ds-perf-plan.
ensureTotalCapacity/initCapacity), not grown incrementallyReleaseSafe cost measured before reaching for ReleaseFast — drop safety checks only when justifiedDebug/ReleaseSafe; any ReleaseFast/ReleaseSmall choice that drops safety checks is deliberate and justifiedtest "..." blocks cover the public surface and error paths — flag notable gaps, not every trivial accessorstd.testing.allocator so leaks fail the testexpectError, not just the happy pathstd.testing.tmpDir only where a real FS is unavoidable<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.