From supeRpowers
Use when diagnosing bugs, errors, or unexpected behavior in R code. Provides a systematic reproduce-isolate-diagnose-fix-test workflow covering browser(), traceback(), debug(), condition handling, and common R pitfalls for both interactive scripts and package code. Triggers: debug, error, bug, traceback, browser, breakpoint, unexpected behavior, stack trace, warning, object not found, wrong results. Do NOT use for performance profiling and optimization — use r-performance instead. Do NOT use for writing tests — use r-tdd instead. For a guided debugging workflow, invoke /r-debug instead.
How this skill is triggered — by the user, by Claude, or both
Slash command
/supeRpowers:r-debuggingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Systematic workflow for diagnosing and fixing bugs in R code:
Systematic workflow for diagnosing and fixing bugs in R code: REPRODUCE -> ISOLATE -> DIAGNOSE -> FIX -> TEST.
Ask upfront: Is this interactive script code or package code? The strategy differs -- package code has formal test infrastructure and namespacing; interactive scripts need ad-hoc reprex and manual verification.
Create a minimal, self-contained example that triggers the bug.
# Use reprex for shareable reproduction cases
reprex::reprex({
library(dplyr)
tibble(x = c(1, NA, 3)) |>
mutate(y = x + 1)
})
Checklist:
sessionInfo() or renv::snapshot()Narrow down where the failure occurs.
Binary search through a pipeline: Comment out the bottom half of a pipe chain. If the error disappears, the bug is in the removed half. Recurse.
Insert browser() at suspect locations:
transform_data <- function(data) {
data <- data |>
filter(!is.na(value))
browser()
# Execution pauses here -- inspect `data` in the console
data |>
summarise(total = sum(value))
}
Inside browser(): n (next), s (step into), c (continue), Q (quit),
ls() (list objects), str(obj) (inspect structure).
Use the right tool for the situation.
# After an error occurs:
traceback()
# For rlang-based errors (tidyverse), get a cleaner tree:
rlang::last_trace()
Read the stack bottom-up: the deepest frame is where the error was thrown; work upward to find your code's entry point.
Quick reference: debug(fn) / debugonce(fn) to step through a function,
trace(fn, tracer = browser, at = 4) to inject a breakpoint at a specific line,
options(error = recover) to drop into browser on any error.
Read references/debugging-tools.md for the full breakpoint command reference,
browser() commands table, and package-specific debugging patterns.
Apply the fix and verify against the original reprex.
devtools::check() for packages, or re-run
the full script for interactive codeWrite a test that would have caught this bug. Future changes must not re-introduce it.
test_that("transform_data handles NA values without error", {
input <- tibble::tibble(value = c(1, NA, 3))
result <- transform_data(input)
expect_equal(result$total, 4)
})
For packages: place in tests/testthat/test-<relevant-file>.R.
For scripts: create a lightweight test file or add to an existing test suite.
Top traps to check first:
as.numeric(factor_var) returns codes, not values — use as.numeric(as.character(x))filter(col > 20) looks for column, not variable — use .data[[col]] for strings, {{ var }} for function argsx == c("A", "B") does element-wise recycling — use %in% for set membershiplist$missing_element returns NULL silently — use [["key"]] with is.null() check0.1 + 0.2 == 0.3 is FALSE — use dplyr::near() or all.equal()Read references/debugging-tools.md for the full gotchas table with detailed explanations, performance debugging tools (profvis, bench::mark), and common performance fixes.
When the root cause is a code quality issue (anti-pattern, poor style, NSE misuse) rather than a logic bug, hand off to the r-code-reviewer agent for a focused review of the problematic code.
Prompt: "My calc_growth() function returns NA for some groups. Help me debug it."
# Input — buggy function
calc_growth <- function(data) {
data |>
arrange(date) |>
mutate(growth = (value - lag(value)) / lag(value) * 100, .by = group)
}
test_data <- tibble(
group = c("A", "A", "B"),
date = as.Date(c("2024-01-01", "2024-02-01", "2024-01-01")),
value = c(100, 120, 50)
)
calc_growth(test_data)
#> Group B has only 1 row -> lag() returns NA -> growth is NA
# Diagnose — insert browser() to inspect
calc_growth <- function(data) {
data <- data |> arrange(group, date)
browser() # inspect: data |> count(group) reveals single-row groups
data |> mutate(growth = (value - lag(value)) / lag(value) * 100, .by = group)
}
# Fix — guard against single-row groups
calc_growth <- function(data) {
data |>
arrange(group, date) |>
mutate(
growth = if (n() > 1) (value - lag(value)) / lag(value) * 100 else NA_real_,
.by = group
)
}
Prompt: "My filter seems to work but returns wrong rows. No error at all."
# Input — subtle recycling bug
df <- tibble(id = 1:6, status = c("A", "B", "C", "A", "B", "C"))
# BAD: intended to keep A and B, but c("A", "B") recycles to match 6 rows
# R compares element-wise: row1=="A", row2=="B", row3=="A", row4=="B"...
df |> filter(status == c("A", "B"))
#> Returns 4 rows — wrong! Recycling matched positions, not values
# GOOD: use %in% for set membership
df |> filter(status %in% c("A", "B"))
#> Returns 4 rows — the correct 4 (all A and B rows)
# Defensive: always use %in% for multi-value comparisons
# If you must use ==, guard with stopifnot(length(x) == length(y))
More example prompts:
Rscript --vanilla"Provides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub alexvantwisk/superpowers --plugin supeRpowers