This skill runs locally or in Claude Code cloud (claude.ai/code) — NOT in CI. It needs write access to the repo to create commits and push to the PR branch.
Phase 1: Plan
- Read the spec: Find the
specs/*.md file in this PR (exclude TEMPLATE.md). If a path is provided in {{ARGUMENTS}}, use that.
- Read CLAUDE.md: Understand architecture, conventions, testing requirements.
- Read
jolt-eval/README.md: Understand the eval framework — the spec's Intent → Invariants and Evaluation → Performance sections may reference it.
- Explore relevant code: Use
explore agents to understand the modules, types, and patterns the implementation will touch.
- Extract evals: Scan the spec's Intent → Invariants and Evaluation → Performance sections for
jolt-eval references and list:
- New invariants to add → each becomes a
/new-invariant <name> subtask.
- New objectives to add → each becomes a
/new-objective <name> subtask.
- Existing invariants/objectives that need to be changed.
- Create implementation plan: Based on the spec's Intent and Execution sections, determine:
- Files to create, modify, or remove
- Order of changes (dependencies first)
- How existing patterns and abstractions should be extended
- Which tasks can run in parallel vs. sequential
- Post the plan as a PR comment for visibility:
**Implementation plan for: {spec title}**
**Changes:**
1. {file/module} — {what changes and why}
2. ...
**Order:** {dependency chain}
**Parallel tasks:** {which can run simultaneously}
**Estimated scope:** {number of files, rough line count}
Phase 2: Execute
- Add jolt-eval scaffolding first: For each new invariant/objective extracted in Phase 1, invoke the corresponding skill so the mechanical checks are in place before the implementation lands:
/new-invariant <name> for each new invariant
/new-objective <name> for each new objective
Commit these additions as their own logical units.
- Implement all changes from the plan.
- Run independent tasks in parallel using agents where beneficial.
- Follow project code style and conventions from CLAUDE.md.
- Performance is critical — avoid regressions in hot paths.
- Commit with clear, well-scoped messages as logical units complete.
Phase 3: QA
Cycle until all checks pass (up to 5 cycles):
- Format:
cargo fmt -q
- Lint (both modes):
cargo clippy --all --features host --message-format=short -q --all-targets -- -D warnings
cargo clippy --all --features host,zk --message-format=short -q --all-targets -- -D warnings
- Test: Run evaluation criteria from the spec, plus:
cargo nextest run -p jolt-prover-legacy muldiv --cargo-quiet --features host
cargo nextest run -p jolt-prover-legacy muldiv --cargo-quiet --features host,zk
cargo nextest run -p jolt-eval --cargo-quiet — runs every invariant's seed-corpus + random-inputs tests; any named in the spec must pass.
- Fix any failures and repeat.
If the same error persists 3 times, stop and post a PR comment describing the fundamental issue.
Phase 4: Validate
Run parallel validation:
- Correctness: All spec evaluation criteria pass.
- Mechanical checks (jolt-eval): For each objective named in the spec's Evaluation → Performance section, run
cargo run -p jolt-eval --bin measure-objectives -- --objective <name> and confirm it moved in the declared direction (or stayed within the declared tolerance). All invariants named or introduced in the spec's Intent → Invariants section must pass — the Phase 3 cargo nextest run -p jolt-eval covers seed corpus + random inputs.
- Code review: Self-review for consistency with existing patterns, missing edge cases, unnecessary changes beyond the spec.
- Security: Check for OWASP top 10 patterns if the changes touch input handling or external data.
Fix any issues found and re-validate.
Phase 5: Finalize
- Update spec status: Change
Status from proposed/approved to implemented in the spec file.
- Push all commits to the PR branch.
- Post summary as a PR comment:
**Implementation complete for: {spec title}**
**Changes made:**
- {file} — {summary}
- ...
**Evaluation results:**
- {criterion 1}: PASS
- {criterion 2}: PASS
- ...
**Tests:** All passing (host + zk modes)
**Lint:** Clean
Task: Implement the spec in this PR. {{ARGUMENTS}}
1---2name: implement-spec3description: Autonomous one-shot implementation from an approved spec (local/cloud only)4---56<Purpose>7Take an approved spec and autonomously implement it: plan the work, execute in parallel where possible, run QA cycles until tests pass, and validate the result. Produces working, verified code from the spec in a single pass.89This skill runs locally or in Claude Code cloud (claude.ai/code) — NOT in CI. It needs write access to the repo to create commits and push to the PR branch.10</Purpose>1112<Execution_Policy>13- The spec is the source of truth. Implement what it says, not more.14- Read CLAUDE.md for project conventions, testing requirements, and architecture.15- Each phase must complete before the next begins.16- Parallel execution within phases where possible.17- If something in the spec is ambiguous, post a PR comment rather than guessing.18- Do not add features, refactor code, or make improvements beyond the spec.19- If the spec lacks the `claude-spec-approved` label, warn that it hasn't been analyzed yet (implementation from an unanalyzed spec risks rework), but proceed if the user insists.20</Execution_Policy>2122<Steps>2324## Phase 1: Plan25261. **Read the spec**: Find the `specs/*.md` file in this PR (exclude `TEMPLATE.md`). If a path is provided in `{{ARGUMENTS}}`, use that.272. **Read CLAUDE.md**: Understand architecture, conventions, testing requirements.283. **Read `jolt-eval/README.md`**: Understand the eval framework — the spec's Intent → Invariants and Evaluation → Performance sections may reference it.294. **Explore relevant code**: Use `explore` agents to understand the modules, types, and patterns the implementation will touch.305. **Extract evals**: Scan the spec's Intent → Invariants and Evaluation → Performance sections for `jolt-eval` references and list:31 - New invariants to add → each becomes a `/new-invariant <name>` subtask.32 - New objectives to add → each becomes a `/new-objective <name>` subtask.33 - Existing invariants/objectives that need to be changed.346. **Create implementation plan**: Based on the spec's Intent and Execution sections, determine:35 - Files to create, modify, or remove36 - Order of changes (dependencies first)37 - How existing patterns and abstractions should be extended38 - Which tasks can run in parallel vs. sequential397. **Post the plan** as a PR comment for visibility:4041```42**Implementation plan for: {spec title}**4344**Changes:**451. {file/module} — {what changes and why}462. ...4748**Order:** {dependency chain}49**Parallel tasks:** {which can run simultaneously}50**Estimated scope:** {number of files, rough line count}51```5253## Phase 2: Execute54551. **Add jolt-eval scaffolding first**: For each new invariant/objective extracted in Phase 1, invoke the corresponding skill so the mechanical checks are in place before the implementation lands:56 - `/new-invariant <name>` for each new invariant57 - `/new-objective <name>` for each new objective58 Commit these additions as their own logical units.592. **Implement** all changes from the plan.60 - Run independent tasks in parallel using agents where beneficial.61 - Follow project code style and conventions from CLAUDE.md.62 - Performance is critical — avoid regressions in hot paths.633. **Commit** with clear, well-scoped messages as logical units complete.6465## Phase 3: QA6667Cycle until all checks pass (up to 5 cycles):68691. **Format**: `cargo fmt -q`702. **Lint** (both modes):71 - `cargo clippy --all --features host --message-format=short -q --all-targets -- -D warnings`72 - `cargo clippy --all --features host,zk --message-format=short -q --all-targets -- -D warnings`733. **Test**: Run evaluation criteria from the spec, plus:74 - `cargo nextest run -p jolt-prover-legacy muldiv --cargo-quiet --features host`75 - `cargo nextest run -p jolt-prover-legacy muldiv --cargo-quiet --features host,zk`76 - `cargo nextest run -p jolt-eval --cargo-quiet` — runs every invariant's seed-corpus + random-inputs tests; any named in the spec must pass.774. **Fix** any failures and repeat.7879If the same error persists 3 times, stop and post a PR comment describing the fundamental issue.8081## Phase 4: Validate8283Run parallel validation:84851. **Correctness**: All spec evaluation criteria pass.862. **Mechanical checks (jolt-eval)**: For each objective named in the spec's Evaluation → Performance section, run `cargo run -p jolt-eval --bin measure-objectives -- --objective <name>` and confirm it moved in the declared direction (or stayed within the declared tolerance). All invariants named or introduced in the spec's Intent → Invariants section must pass — the Phase 3 `cargo nextest run -p jolt-eval` covers seed corpus + random inputs.873. **Code review**: Self-review for consistency with existing patterns, missing edge cases, unnecessary changes beyond the spec.884. **Security**: Check for OWASP top 10 patterns if the changes touch input handling or external data.8990Fix any issues found and re-validate.9192## Phase 5: Finalize93941. **Update spec status**: Change `Status` from `proposed`/`approved` to `implemented` in the spec file.952. **Push** all commits to the PR branch.963. **Post summary** as a PR comment:9798```99**Implementation complete for: {spec title}**100101**Changes made:**102- {file} — {summary}103- ...104105**Evaluation results:**106- {criterion 1}: PASS107- {criterion 2}: PASS108- ...109110**Tests:** All passing (host + zk modes)111**Lint:** Clean112```113114</Steps>115116Task: Implement the spec in this PR. {{ARGUMENTS}}