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 mhawthorne/gza --skill gza-code-review-fullgit clone --depth 1 https://github.com/mhawthorne/gzaWrote 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/mhawthorne/gza/gza-code-review-full)<a href="https://agentmods.dev/skills/mhawthorne/gza/gza-code-review-full"><img src="https://agentmods.dev/badge/skills/mhawthorne/gza/gza-code-review-full/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/mhawthorne/gza/gza-code-review-full"><img src="https://agentmods.dev/badge/skills/mhawthorne/gza/gza-code-review-full.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00022 | $0.03811 |
| Opus 5 | $0.00011 | $0.01906 |
| Sonnet 5 | $0.00004 | $0.00762 |
| Haiku 4.5 | $0.00002 | $0.00381 |
Grade A, and why
gza-code-review-full scanned grade A with 1 finding 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 9d 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.
Runs shell commandslowCapability
Expected in a hook, worth knowing in a rule or an instructions file.
grep -n "subprocess.run" src/gza/*.py How it starts
The opening of the file, as written. The whole thing — 534 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Full Codebase Code Review
Perform a comprehensive code review of the gza codebase, suitable for pre-release assessment. This review covers:
- Unit test coverage
- Functional test coverage
- Code duplication
- Component interaction patterns
- Error handling consistency
- API/interface consistency
- Configuration and hardcoding audit
- Logging and observability
- Resource management
- Type safety
When to Use
- Before a release to assess codebase health
- When you want a comprehensive quality check
- To identify areas needing more tests or refactoring
Output
Write findings to reviews/<timestamp>-code-review-full-<model>.md in the project root, where <timestamp> is the current date/time in YYYYmmddHHMMSS format and <model> is a short identifier for the model performing the review (e.g., reviews/20260305114139-code-review-full-opus-4-6.md). Use your own model name/ID to derive the short identifier.
Process
Step 1: Inventory the codebase
Map out the source modules and test files:
-
List all source modules:
ls -la src/gza/*.py ls -la src/gza/providers/*.py -
List all test files:
ls -la tests/*.py ls -la tests_integration/*.py 2>/dev/null || echo "No integration tests dir" -
Create a mapping of source file → test file(s):
db.py→test_db.pycli.py→test_cli.py- etc.
-
Identify untested modules - source files with no corresponding test file
Step 2: Assess unit test coverage
For each source module:
-
Read the source file to understand its public interface (functions, classes, methods)
-
Read the corresponding test file (if exists)
-
Check coverage by listing:
- Functions/methods that ARE tested
- Functions/methods that are NOT tested
- Edge cases that aren't covered (error paths, boundary conditions)
-
Run the tests to verify they pass:
uv run pytest tests/ -v --tb=short
Focus especially on:
db.py- Core task storage, critical for correctnesscli.py- User-facing commands, all subcommands should have testsrunner.py- Task execution logicgit.py- Git operations (mocked tests preferred)github.py- GitHub integration
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.
- 9d ago First seen · 534 lines · 22 tokens per session scan A bb53870a694b
gza-code-review-full is a skill published in the GitHub repository mhawthorne/gza (12 stars, last pushed yesterday), licensed MIT. It adds 22 tokens to every session and 3,811 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 1 finding (runs shell commands). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
verify-change
A change-checking skill that reviews code differences and checks whether related documentation, tests, and records were updated.
verify-quality
A code-quality checker that measures complexity, size, naming, and common code smells. It reports problems such as duplicated code, unused code, and overly long functions.
verify-module
A module-checking skill that scans a project’s folders, code, and documentation. It expects each module to include a README.md and DESIGN.md, which explain how the module is used and why it was designed that way.
criticism-self-criticism
A structured review method for examining completed work, criticism, and repeated mistakes. It focuses on specific evidence, causes, effects, and practical improvements.
planning
ONLY for coordinated multi-artifact work: multiple workflows with dependencies, shared data-table schema/migration across tasks, or the user explicitly asked to review a plan first. Load create-tasks via loadtool before calling it (search "create tasks" if not visible). Do NOT use for new one-off workflows…
flow-next-impl-review
Carmack-level implementation review of changes via the configured backend. Use when asked to review code or a diff in a flow-next repo.