new-spec
Create a new spec file in specs/ by interviewing the user to fill each section of the template. The goal: produce a spec that would pass /analyze-spec with zero ambiguity on the first try.
Steps
1. Initialize
- Validate the argument: must be lowercase alphanumeric with dashes (e.g.
streaming-prover). Reject otherwise. - Get the GitHub username: run
gh api user --jq .login. - Get today's date in
YYYY-MM-DDformat. - Read
specs/TEMPLATE.mdto understand the required sections. - Read
jolt-eval/README.mdto understand the eval framework — you'll reference it when prompting the user about mechanical verifiability. - Explore the codebase to understand what areas the feature name suggests — run an
exploreagent to gather context. This informs your questions.
2. Interview — Section by Section
Walk through each template section with the user. For each section, ask targeted questions until you have enough to write it with zero ambiguity. Do NOT move to the next section until the current one is clear.
One question at a time. Never batch.
More from a16z/jolt
jolt
Wrap a Rust function in a Jolt zero-knowledge proof
15new-objective
Implement a new objective for jolt-eval
3new-invariant
Implement a new invariant for jolt-eval
3implement-spec
Autonomous one-shot implementation from an approved spec (local/cloud only)
3analyze-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