implement-spec

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. </Purpose>

<Execution_Policy>

• The spec is the source of truth. Implement what it says, not more.
• Read CLAUDE.md for project conventions, testing requirements, and architecture.
• Each phase must complete before the next begins.
• Parallel execution within phases where possible.
• Resolve routine implementation choices from the spec and repository conventions. For ambiguity affecting correctness, scope, or acceptance criteria, post a focused PR question and continue unaffected work.
• Do not add features, refactor code, or make improvements beyond the spec.
• If the spec lacks the claude-spec-approved label, note that it hasn't been analyzed. An explicit user instruction to implement it is sufficient authorization; otherwise request approval. </Execution_Policy>

Phase 1: Plan

1. Read the spec: Find the specs/*.md file in this PR (exclude TEMPLATE.md). If a path is provided in {{ARGUMENTS}}, use that.
2. Read CLAUDE.md: Understand architecture, conventions, testing requirements.
3. Read jolt-eval/README.md: Understand the eval framework — the spec's Intent → Invariants and Evaluation → Performance sections may reference it.
4. Explore relevant code: Use explore agents to understand the modules, types, and patterns the implementation will touch.
5. 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.
6. 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
7. 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

1. 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.
2. 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.
3. Commit with clear, well-scoped messages as logical units complete.

Phase 3: QA

Run the checks sequentially until all pass (up to 5 cycles). Repeat checks only when a failure or subsequent change requires it; complete the full matrix before handoff.

1. Format: cargo fmt -q
2. 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
3. Test: Run evaluation criteria from the spec, plus:
   • cargo nextest run -p jolt-verifier standard_muldiv --features prover-fixtures --cargo-quiet
   • cargo nextest run -p jolt-prover --features prover-fixtures --cargo-quiet
   • cargo nextest run -p jolt-prover --features prover-fixtures,zk --cargo-quiet
   • cargo nextest run -p jolt-prover --features akita,prover-fixtures --cargo-quiet
   • cargo nextest run -p jolt-eval --cargo-quiet — runs every invariant's seed-corpus + random-inputs tests; any named in the spec must pass.
4. 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

Validate the result, reusing Phase 3 results unless subsequent changes invalidate them:

1. Correctness: All spec evaluation criteria pass.
2. 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.
3. Code review: Self-review for consistency with existing patterns, missing edge cases, unnecessary changes beyond the spec.
4. 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

1. Update spec status: Change Status from proposed/approved to implemented in the spec file.
2. Push all commits to the PR branch.
3. 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}}