snarkvm-fix

name	snarkvm-fix
description	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.
allowed-tools	Bash, Read, Write, Grep, Glob, Task, AskUserQuestion

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

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:

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:

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.