Fix snarkVM Issues with TDD Workflow

Fix GitHub issues or PR review feedback in snarkVM using test-driven development. Includes investigation, planning, and implementation with final validation.

Sby Skills Guide Bot
DevelopmentAdvanced0 views0 installs3/8/2026
Claude CodeCursor
snarkvmtddbug-fixinggithub-integrationtesting

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.

Related skills