new-invariant
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.
<Execution_Policy>
- The user must provide an invariant name (lowercase with underscores, e.g.
sumcheck_binding). - Ask the user what property is being checked and what the input type should look like 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>
Phase 1: Gather Requirements
- Validate the argument
{{ARGUMENTS}}: must be a valid Rust identifier (lowercase alphanumeric + underscores). Reject otherwise. - Ask the user:
More from a16z/jolt
jolt
Wrap a Rust function in a Jolt zero-knowledge proof
15new-objective
Implement a new objective for jolt-eval
3implement-spec
Autonomous one-shot implementation from an approved spec (local/cloud only)
3new-spec
Create a new spec through Socratic interview, filling each template section to zero ambiguity
2analyze-spec
Spec analysis with ambiguity scoring — interactive locally, single-pass remotely via label
2ci-code-review
Deep code review of a pull request using parallel analysis agents (semantic consistency, bugs, tech debt, security). USE FOR: - Reviewing PRs for bugs, security issues, and code quality - Analyzing new abstractions for consistency and correctness - Identifying tech debt and architectural concerns - Posting review comments to specific lines on GitHub TRIGGERS: - "review PR", "code review", "review changes" - "diff review", "PR feedback", "check PR" - "analyze diff", "critique code", "review code" - "pull request review", "GitHub PR review"
2