new-invariant
Skill1.1k starsChanged 13 days agoApache-2.0View on GitHub
Implement a new invariant for jolt-eval
We split this skill into the rules it gives an agent
18 rules. About 0 are common, 6 are distinctive, and 12 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
12
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Use the request, spec, and repository context to establish the property and input type.
- Distinctive: line 16
Follow existing patterns exactly — study the split_eq_bind and soundness invariants as models.
- Distinctive: line 17
Always run clippy and the auto-generated tests before reporting success.
- Very specific: line 33
Read jolt-eval/src/invariant/mod.rs to understand the current JoltInvariants enum and dispatch!
- Distinctive: line 34
Read an existing invariant for reference:
- Very specific: line 41
Create the invariant file at jolt-eval/src/invariant/<invariant_name>.rs with:
- Very specific: line 59
Must derive Debug, Clone, Serialize, Deserialize, JsonSchema
- Very specific: line 60
Must implement Arbitrary manually (for fuzzing)
- Very specific: line 61
Use bounded ranges in Arbitrary impl (e.g.
- Very specific: line 90
Use CheckError::InvalidInput for degenerate inputs that should be skipped (not counted as violations)
- Very specific: line 91
Use CheckError::Violation(InvariantViolation::with_details(...)) for actual violations — include diagnostic info
- Very specific: line 98
Add pub mod <invariant_name>.
- Very specific: line 99
Add a variant to JoltInvariants:
- Very specific: line 103
Add the variant to JoltInvariants::all():
- Very specific: line 107
Use <Name>Invariant::default() if the struct has fields.
- Very specific: line 108
Add the variant to the dispatch!
- Distinctive: line 127
Run these commands (all must pass):
- Distinctive: line 143
If any step fails, fix the issue and re-run.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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
<Purpose>
Implement a new invariant for the jolt-eval framework. An invariant is a property that must always hold — the framework can test it with seed inputs, fuzz it with random/structured inputs, and red-team it with an AI agent.This skill handles all the boilerplate: creating the invariant struct + input type, implementing the Invariant trait, registering it in the JoltInvariants enum, creating a fuzz target (if applicable), and running sync_targets.sh.
</Purpose>
<Execution_Policy>
- The user must provide an invariant name (lowercase with underscores, e.g.
sumcheck_binding). - Use the request, spec, and repository context to establish the property and input type; ask only for missing requirements before writing code.
- Follow existing patterns exactly — study the split_eq_bind and soundness invariants as models.
- Always run clippy and the auto-generated tests before reporting success. </Execution_Policy>
<Steps>Phase 1: Gather Requirements
- Validate the argument
{{ARGUMENTS}}: must be a valid Rust identifier (lowercase alphanumeric + underscores). Reject otherwise. - Gather these requirements from existing context; ask the user only for missing information:
- What property does this invariant check? (becomes the
description()) - What does the input look like? (fields, types, ranges)
- What synthesis targets should it support? (
Test,Fuzz,RedTeam) - Does it need non-trivial setup? (e.g. preprocessing, compilation — default to
Setup = ())
- What property does this invariant check? (becomes the
Phase 2: Explore Context
- Read
jolt-eval/src/invariant/mod.rsto understand the currentJoltInvariantsenum anddispatch!macro. - Read an existing invariant for reference:
- Simple:
jolt-eval/src/invariant/split_eq_bind.rs - Complex (with setup, enrich_input):
jolt-eval/src/invariant/soundness.rs
- Simple:
- Explore the modular crates that own the tested types and APIs.
Phase 3: Implement
Create the invariant file at jolt-eval/src/invariant/<invariant_name>.rs with:
Input Type
#[derive(Debug, Clone, serde::Serialize, serde::Deserialize, schemars::JsonSchema)]
pub struct <Name>Input {
// fields
}
impl<'a> Arbitrary<'a> for <Name>Input {
fn arbitrary(u: &mut Unstructured<'a>) -> arbitrary::Result<Self> {
// Generate random inputs with reasonable bounds
}
}Key requirements for the input type:
- Must derive
Debug,Clone,Serialize,Deserialize,JsonSchema - Must implement
Arbitrarymanually (for fuzzing) - Use bounded ranges in
Arbitraryimpl (e.g.u.int_in_range(2..=16)?) to keep inputs meaningful
Invariant Struct
#[jolt_eval_macros::invariant(Test, Fuzz, RedTeam)] // adjust targets as needed
#[derive(Default)]
pub struct <Name>Invariant;
impl Invariant for <Name>Invariant {
type Setup = (); // or a custom setup type
type Input = <Name>Input;
fn name(&self) -> &str { "<invariant_name>" }
fn description(&self) -> String { "...".into() }
fn setup(&self) -> Self::Setup { /* ... */ }
fn check(&self, setup: &Self::Setup, input: Self::Input) -> Result<(), CheckError> {
// 1. Validate input — return Err(CheckError::InvalidInput(...)) for degenerate cases
// 2. Run the property check
// 3. Return Ok(()) if the invariant holds
// 4. Return Err(CheckError::Violation(...)) if violated
}
fn seed_corpus(&self) -> Vec<Self::Input> {
// Include: minimal case, typical case, edge case (large values, boundary conditions)
}
}Guidelines for check()
- Use
CheckError::InvalidInputfor degenerate inputs that should be skipped (not counted as violations) - Use
CheckError::Violation(InvariantViolation::with_details(...))for actual violations — include diagnostic info - Compare against a known-correct reference implementation when testing optimized code
Phase 4: Register
Edit jolt-eval/src/invariant/mod.rs:
- Add
pub mod <invariant_name>;to the module declarations at the top. - Add a variant to
JoltInvariants:<VariantName>(<invariant_name>::<Name>Invariant), - Add the variant to
JoltInvariants::all():
UseSelf::<VariantName>(<invariant_name>::<Name>Invariant),<Name>Invariant::default()if the struct has fields. - Add the variant to the
dispatch!macro:JoltInvariants::<VariantName>($inv) => $body,
Phase 5: Create Fuzz Target (if targets include Fuzz)
Create jolt-eval/fuzz/fuzz_targets/<invariant_name>.rs:
#![no_main]
use jolt_eval::invariant::<invariant_name>::<Name>Invariant;
jolt_eval::fuzz_invariant!(<Name>Invariant::default());Then run ./jolt-eval/sync_targets.sh to update fuzz/Cargo.toml.
Phase 6: Validate
Run these commands (all must pass):
# Format
cargo fmt -q
# Lint
cargo clippy -p jolt-eval -q --all-targets -- -D warnings
# Run auto-generated tests (seed_corpus + random_inputs)
cargo nextest run -p jolt-eval --cargo-quiet invariant::<invariant_name>
# If fuzz target was created, verify it compiles
cd jolt-eval/fuzz && cargo check 2>&1 | head -20If any step fails, fix the issue and re-run.
</Steps>Task: Implement a new invariant for jolt-eval. {{ARGUMENTS}}
Trending
More talk lately.about the whole repository
Who's talking about a16z/jolt
- coset-io/zkp-academy“[2024.4.23-2024.5.21] Lasso & Jolt 学习小组”GitHub · Apr 27, 2024 · 2 reactions
- LayerZero-Labs/akita“perf(verifier): batch verifier dot products through jolt-field row kernels”GitHub · Oct 6, 2026
- sudosubin/agents.nix“agent-skills.github.a16z.jolt: 1.1.1-unstable-2026-09-02 → 1.1.1-unstable-2026-09-25”GitHub · Oct 3, 2026
- LayerZero-Labs/jolt“chore(akita): bump dependency to e2c49ed”GitHub · Oct 2, 2026
- jruizaranguren/best-of-digital-identity“Add privacy-preserving identity category”GitHub · Sep 30, 2026
The biggest 5 of 33 mentions linking to the repository that our crawl found. Each line is their own headline.
See all 33
Talked about on GitHub (33 times).
On GitHub · 33
- Apr 27, 2024[2024.4.23-2024.5.21] Lasso & Jolt 学习小组 — coset-io/zkp-academy2 reactions · 1 comment
- Oct 6, 2026perf(verifier): batch verifier dot products through jolt-field row kernels — LayerZero-Labs/akita0 reactions · 15 comments
- Oct 3, 2026agent-skills.github.a16z.jolt: 1.1.1-unstable-2026-09-02 → 1.1.1-unstable-2026-09-25 — sudosubin/agents.nix0 reactions
- Oct 2, 2026chore(akita): bump dependency to e2c49ed — LayerZero-Labs/jolt0 reactions · 3 comments
- Sep 30, 2026Add privacy-preserving identity category — jruizaranguren/best-of-digital-identity0 reactions
28 more on GitHub
- Sep 30, 2026build: jolt as public git deps at a16z/jolt feat/inline-extension-external — 0xAndoroid/jeth0 reactions
- Sep 24, 2026agent-skills.github.a16z.jolt: init at 1.1.1-unstable-2026-09-02 — sudosubin/agents.nix0 reactions
- Aug 10, 2026Feat/jolt prover akita — LayerZero-Labs/jolt0 reactions · 1 comment
- Jul 31, 2026feat: port the demo to the modular prover on Akita (non-zk) — 0xAndoroid/jolt-wasm-prover0 reactions · 1 comment
- Jul 23, 2026Feat/jolt legacy prover akita integration — LayerZero-Labs/jolt0 reactions
- Jul 22, 2026[arXiv] zkML ONNX inference-proof harness — Jolt Atlas: Verifiable Inference via Lookup Arguments in Zero Knowledge — mnemonik-dev/nightly-research0 reactions
- May 21, 2026docs: document precommitted polynomial reductions — LayerZero-Labs/jolt0 reactions · 2 comments
- May 21, 2026feat: integrate bytecode and program image reductions — LayerZero-Labs/jolt0 reactions · 2 comments
- May 21, 2026feat: add committed bytecode foundation — LayerZero-Labs/jolt0 reactions · 2 comments
- May 21, 2026refactor: add precommitted polynomial reductions — LayerZero-Labs/jolt0 reactions · 2 comments
- May 21, 2026refactor: split stage 6 sumchecks — LayerZero-Labs/jolt0 reactions · 2 comments
- Apr 15, 2026build(deps): bump jolt-sdk from `b10e80a` to `3d5e431` — gg-archive/ruma-zk0 reactions
- Feb 3, 2026Implement Jolt Keccak-256 benchmark — ethereum/csp-benchmarkssays it tested it0 reactions
- Feb 3, 2026Implement Jolt ECDSA benchmark — ethereum/csp-benchmarkssays it tested it0 reactions
- Nov 11, 2025fix: correct calculation of max_log_n in VerifierSetup — markosg04/dory0 reactions
- Aug 15, 2025Update Jolt to v0.3.0-alpha — eth-act/ere0 reactions
- Aug 4, 2025Wire up PCS to jolt-prover — ICME-Lab/jolt-atlas0 reactions · 1 comment
- Aug 2, 2025Implement output proof — ICME-Lab/zkml-jolt0 reactions
- Mar 22, 2025no rust-toolchain-aarch64-unknown-linux-gnu.tar.gz release version — a16z/rust0 reactions · 1 comment
- Mar 21, 2025Implement `CanonicalSerialize` and `CanonicalDeserialize` for signed integers — a16z/arkworks-algebra0 reactions
- Mar 5, 2025Trait solver taking >10s to finish in auto complete — rust-lang/rust-analyzer0 reactions · 2 comments
- Feb 28, 2025Add Jolt zkVM Support to ProofLab — ProofLabDev/prooflab-rs0 reactions
- Feb 25, 2025chore: fix typos — a16z/helios0 reactions
- Jan 15, 2025Benchmark ICICLE and `arkmsm` — piotr-roslaniec/wasm-multiexp-benchsays it tested it0 reactions
- Nov 22, 2024chore: Update toolchain to nightly-2024-09-30 — a16z/rust0 reactions
- Jun 26, 2024Optimize polynomial batching computation — microsoft/Nova0 reactions · 1 comment
- May 27, 2024Summary from our mail threads — mab-xyz/verifiable-client-diversity0 reactions
- May 15, 2024List of Existing ZkVMs — vacp2p/zk-explorations0 reactions
In this repository9 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- analyze-specSkill
- ci-code-reviewSkill
- comment-policySkill
- implement-specSkill
- new-objectiveSkill
- new-specSkill
- test-policySkill
- update-docsSkill
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.

