| name | zig-review |
| description | Comprehensive Zig code review across all quality dimensions. Triggers on /zig-review. Runs parallel subagents — each using an existing skill — for Tiger Style compliance, Zig 0.15 idiom correctness, deslop, simplification opportunities, and API design quality. Always operates on the full branch diff against main. Report-only: never makes changes.
|
Zig Review
Step 1: Get the diff
git diff main...HEAD
Fall back to git diff HEAD if that returns nothing.
Step 2: Launch five parallel review agents
Spawn all five in a single message so they run concurrently. Each agent receives the full diff. All agents are report-only — they must not make changes.
Tiger Style agent:
Use the tiger-style skill to review the following diff. Report violations only — do not make any changes. For each finding include the file and approximate line, what rule is violated, and whether it is a must-fix or a suggestion.
[full diff]
Zig idioms agent:
Use the zig skill to review the following diff for Zig 0.15 correctness issues and outdated patterns. Report findings only — do not make any changes. For each finding include the file and approximate line, what the issue is, and the correct 0.15 pattern.
[full diff]
Deslop agent:
Use the deslop skill to review the following diff for AI-generated comment slop. Report findings only — do not remove any comments. For each finding include the file and approximate line, the comment text, and why it is slop.
[full diff]
Simplify agent:
Use the simplify skill to review the following diff for simplification opportunities. Report opportunities only — do not make any changes. For each finding include the file and approximate line and a concise description of what could be simplified and why.
[full diff]
API design agent:
Review the following diff for public API and interface design quality. Report findings only — do not make any changes.
Focus on:
- Clarity: Are public function names, parameter names, and types self-documenting? Would a caller understand usage without reading the implementation?
- Ergonomics: Is the call site pleasant? Are common cases easy and advanced cases possible?
- Minimalism: Is the public surface as small as it can be? Are internals leaking that should be private?
- Consistency: Is naming and shape consistent with the rest of the public API and Zig stdlib conventions?
- Error contracts: Are error types informative? Can callers distinguish and handle errors meaningfully?
- Ownership semantics: Is it clear who owns memory at the call boundary? Are lifetimes obvious from the types?
- Composability: Does the API compose well with Zig idioms (allocators, error unions, optionals)?
[full diff]
Step 3: Aggregate results
Once all agents return, filter before reporting. Drop any finding that:
- Has no concrete, unambiguous fix ("consider whether...", "you could also...")
- Is already enforced by the compiler or type system
- Is a naming quibble where the existing name is already clear
- Would generate disagreement between two reasonable engineers
- Requires context the reviewer doesn't have
- Would itself generate new findings if acted on (too vague to be actionable)
If you applied every surviving finding and re-ran the review, it should come back clean.
Then produce the report:
## Tiger Style
[must-fix findings, then suggestions — or "No issues found."]
## Zig Idioms
[findings — or "No issues found."]
## Deslop
[findings — or "No issues found."]
## Simplify
[findings — or "No issues found."]
## API Design
[findings — or "No issues found."]
---
**Summary:** X must-fix, Y suggestions across Z categories.
Keep findings concise — one line per issue where possible, with file and line context.
