# Snarkvm Fix

> Fix GitHub issues or PR review feedback in snarkVM using TDD workflow. WHEN: User says "fix issue", "fix #123", "fix pr", "fix PR feedback", "address review comments", "resolve review threads", or wants to fix a bug/feature request from GitHub issues or address reviewer requests. WHEN NOT: Doing security review (use snarkvm-review), fetching context only (use snarkvm-github), or working on non-snarkVM code.

- Skill: `provablehq/snarkvm-fix` (Agent Skill)
- Install (CLI): `npx skillmds@latest add provablehq/snarkvm-fix`
- Raw SKILL.md: https://api.skillmd.com/api/skills/provablehq/snarkvm-fix/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: provablehq (https://skillmd.com/u/provablehq)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/provablehq/snarkvm-fix

---


# Fix Issue or PR Feedback

Fix snarkVM GitHub issues or PR review comments using test-driven development.

## Usage

```
/snarkvm-fix issue <number>
/snarkvm-fix pr <number>
```

## Setup

```bash
MODE="${ARGUMENTS%% *}"   # "issue" or "pr"
NUM="${ARGUMENTS#* }"     # the number
WS=".claude/workspace"
SKILL_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")/../snarkvm-github" && pwd)"
```

## 1. Load Context

**For issues:**
```bash
if [[ ! -f "$WS/state-issue-$NUM.md" ]]; then
  "$SKILL_DIR/scripts/fetch-issue.sh" "$NUM"
fi
```
Review: `$WS/state-issue-$NUM.md` and recent comments.

**For PRs:**
```bash
if [[ ! -f "$WS/state-pr-$NUM.md" ]]; then
  "$SKILL_DIR/scripts/fetch-pr.sh" "$NUM"
fi
"$SKILL_DIR/scripts/refresh-threads.sh" "$NUM"
```
Review: `$WS/state-pr-$NUM.md`, `$WS/unresolved-pr-$NUM.json`, and `$WS/handoff-pr-$NUM.md` if present.

## 2. Investigate

**For issues** — search for related code. Answer:
1. What is the expected vs actual behavior?
2. Where does the code path go wrong?
3. What are the edge cases?

**For PRs** — analyze each unresolved comment:

| # | Path:Line | Reviewer | Request | Type | Risk |
|---|-----------|----------|---------|------|------|

**Where to look:**
- Console type bugs -> `console/` (types, program, network)
- Circuit bugs -> `circuit/` (must stay in sync with console)
- Synthesizer bugs -> `synthesizer/` (program execution, VM, process)
- Crypto bugs -> `algorithms/` (Poseidon, Marlin, Polycommit)
- Serialization bugs -> check `ToBytes`/`FromBytes`/`Serialize`/`Deserialize` impls

**Think hard. Do not proceed until you understand the root cause or each request.**

## 3. Plan (APPROVAL REQUIRED)

Present a concrete plan:

| # | Location | Change | Test | Risk |
|---|----------|--------|------|------|

**Use AskUserQuestion to get explicit approval before proceeding.**

## 4. Implement (TDD)

For each change:
1. **Write failing test** that reproduces the bug or covers the new behavior
2. **Verify it fails**: `cargo test -p <crate> -- test_name --nocapture`
3. **Implement minimal fix** — match existing code style
4. **Verify it passes**: `cargo test -p <crate> -- test_name --nocapture`

For pure style/nit fixes (no behavioral change), batch them without tests.

## 5. Final Validation

Validate affected crates per AGENTS.md.

## 6. Report

```
**Target**: #NUM — [title]
**Root cause**: [brief explanation]
**Fix**: [what changed and why]
**Test**: [what the test verifies]
**Files changed**:
- path/to/file.rs — [change description]
```

**Do not commit unless explicitly asked.**

## Handling Disagreements (PR mode)

If you disagree with a review comment:
1. Explain your reasoning with evidence
2. Propose an alternative if applicable
3. **Use AskUserQuestion** to discuss before proceeding

Never silently ignore review feedback.