Jolt is a zero-knowledge virtual machine for RISC-V that enables programs to be executed and cryptographically proven. It is for developers and contributors working with zero-knowledge proofs and virtual machines, while the catalogue entries provide instructions and skills for using or developing Jolt.
Borrowing it
Nothing to install: this file belongs to a16z/jolt. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/a16z/jolt/main/.claude/skills/ci-code-review/SKILL.mdgit clone --depth 1 https://github.com/a16z/joltWrote 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/a16z/jolt/ci-code-review)<a href="https://agentmods.dev/skills/a16z/jolt/ci-code-review"><img src="https://agentmods.dev/badge/skills/a16z/jolt/ci-code-review/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/a16z/jolt/ci-code-review"><img src="https://agentmods.dev/badge/skills/a16z/jolt/ci-code-review.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.00129 | $0.01844 |
| Opus 5.5 | $0.00052 | $0.00738 |
| Sonnet 5.5 | $0.00026 | $0.00369 |
| Haiku 4.5 | $0.00013 | $0.00184 |
Grade A, and why
ci-code-review 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 1mo 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 — 141 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Provide a code review for the given pull request.
Follow these steps:
-
Eligibility Check (Sonnet): Check if the PR (a) is closed, (b) is automated/trivial. If so, stop.
-
PR Analysis (Fable): View the PR and return:
- Summary of the change and its purpose
- List of new functions, types, enums, or abstractions introduced
- For each new abstraction: its name, stated purpose (from comments/docs), and intended usage contract
-
Parallel Deep Review (4 Fable agents):
Pass the PR summary and new abstractions list to each agent.
a. Semantic Consistency Agent: For each new function/type/enum introduced:
- Read its definition, documentation, and any comments describing when/how it should be used
- Find ALL usages of that abstraction within the PR
- Verify each usage matches the documented intent
- Flag misuse: e.g., error-handling functions called for wrong error types, validation functions bypassed, enums used inconsistently
- Pay special attention to: panic/error functions (when should they trigger?), unsafe blocks, security-sensitive operations
b. Deep Bug Analysis Agent: Read the full context of modified files (not just diff lines).
- Understand the data flow and control flow around changes
- Check for logic errors, edge cases, off-by-one errors, resource leaks
- Verify error handling is appropriate for each failure mode
- Check that invariants are maintained across the changes
c. Tech Debt Removal Agent:
- Understand new abstractions that are introduced, new functions/types/enums
- Identify possible future usecases for these things and understand whether abstractions meet future requirements
- See which paradigms of Rust (or other language) development are used and whether they apply here
- Identify possible improvements that would benefit long term maintainability of the code
- Be an enjoyer of abstractions: generics, traits, dyn, enums, etc.
d. Security Reviewer Agent:
- Identify whether changes to the protocol do not break soundness
- Identify possible attack vectors that are introduced with these changes
- Check for input validation gaps at trust boundaries (user input, network data, file I/O, IPC)
- Verify authentication/authorization checks are not bypassed or weakened
- Look for injection risks: SQL, command, path traversal, template injection, deserialization
- Check cryptographic usage: hardcoded secrets, weak algorithms, nonce reuse, timing side-channels
- Verify resource limits: unbounded allocations, missing timeouts, denial-of-service vectors
- Check concurrency: TOCTOU races, lock ordering, shared mutable state without synchronization
-
Validate Issues (MANDATORY — do not skip):
After collecting all issues from the 4 agents, validate every issue scored >= 50.
For each issue from the agents:
- For complex logic/semantic issues, reason through whether the bug is real and exploitable.
- For mechanically checkable issues, inspect existing tests and CI results; do not run builds or tests unless the user explicitly requests them.
Score each issue 0-100 AFTER validation:
- 0: False positive, doesn't stand up to scrutiny, or pre-existing issue
- 25: Might be real, but couldn't verify. Stylistic issues without explicit guidance.
- 50: Verified real issue, but minor/nitpick. Not important relative to PR scope.
- 75: Verified real issue that will impact functionality. Insufficient existing approach.
- 100: Confirmed real issue that will happen frequently. Direct evidence confirms it.
-
Post comments to PR: Always post a single review to the PR so the author has confirmation that the review ran, regardless of whether issues were found.
- When there are validated issues with score >= 50, include them in the
commentsarray. - When there are none, post the review with an empty
commentsarray and a body that briefly states no issues were found (1-2 sentences, same tone as the comment guidelines below — concise, senior-engineer voice, no scores/severity labels/ceremony).
- When there are validated issues with score >= 50, include them in the
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.
- 1mo ago Changed 07413ac46dd4
- 2mo ago First seen · 141 lines · 129 tokens per session scan A 677454d1c6b1
ci-code-review is a skill published in the GitHub repository a16z/jolt (1,059 stars, last pushed today), licensed Apache-2.0. It adds 129 tokens to every session and 1,844 once invoked, about $0.0005 per session on Opus 5.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-08-30.
Other skills, from other repositories
implementing-zero-knowledge-proof-for-authentication
Zero-Knowledge Proofs (ZKPs) allow a prover to demonstrate knowledge of a secret (such as a password or private key) without revealing the secret itself. This skill implements the Schnorr identificati.
zero-knowledge-proofs
Use this skill when the user says 'ZK circuit', 'Circom', 'zk-SNARK', 'Groth16', 'PLONK', 'trusted setup', 'ptau', 'privacy-preserving proof'. Covers writing arithmetic circuits (Circom), choosing a proving system, and the trusted-setup lifecycle. Do NOT use for: full ZK domain reference (use…
flounder
Operates Flounder, an autonomous white-hat security auditor. Use when a user asks for a security audit, bug-bounty review, vulnerability investigation, or exploit proof for a public-source or authorized repository, source tree, package, smart contract, Solidity/EVM project, ZK or proof-system code, deployed address…
zkp-toolkit
Zero-Knowledge Proof utilities - proof generation, verification, selective disclosure, ZK-Rollup batching, and benchmarking across ZK systems.
release-pr-review
Review pass on an open release PR (release/ → main) — the step between git-wrapup and release-and-publish when a project releases in gated release PR mode. Reads the PR's commit range through the code-simplifier lens plus a correctness review, verifies whatever an automated reviewer left on the PR, lands fixes as…
code-simplifier
Cleanup pass that edits the working tree — over a session's uncommitted changes, or a named path or whole codebase. Reads git diff (or the named target) and simplifies, consolidates, and aligns code with the existing codebase — modernize syntax, cut unnecessary complexity and slop, consolidate duplicated logic, catch…