templates/skills/languages/r/SKILL.md
Execute these commands after EVERY implementation (see AGENT_AUTOMATION module for full workflow).
npx skillsauth add hivellm/rulebook RInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
CRITICAL: Execute these commands after EVERY implementation (see AGENT_AUTOMATION module for full workflow).
# Complete quality check sequence:
Rscript -e 'styler::style_pkg(dry="on")' # Format check
Rscript -e 'lintr::lint_package()' # Linting
R CMD check . # Full check
Rscript -e 'devtools::test()' # All tests
# Security audit:
Rscript -e 'pak::pkg_deps_explain()' # Dependency check
CRITICAL: Use R 4.2+ with modern package development tools.
Package: yourpackage
Type: Package
Title: Your Package Title
Version: 0.1.0
Author: Your Name
Maintainer: Your Name <[email protected]>
Description: A comprehensive description of what your package does.
License: MIT + file LICENSE
Encoding: UTF-8
LazyData: true
Roxygen: list(markdown = TRUE)
RoxygenNote: 7.2.3
Depends:
R (>= 4.2)
Imports:
dplyr (>= 1.1.0),
ggplot2 (>= 3.4.0)
Suggests:
testthat (>= 3.0.0),
knitr,
rmarkdown
VignetteBuilder: knitr
CRITICAL: After implementing ANY feature, you MUST run these commands in order.
IMPORTANT: These commands MUST match your GitHub Actions workflows to prevent CI/CD failures!
# Pre-Commit Checklist (MUST match .github/workflows/*.yml)
# 1. Format check (matches workflow - use dry="on"!)
Rscript -e "styler::style_pkg(dry = 'on')"
# 2. Lint (MUST pass with no warnings - matches workflow)
Rscript -e "lintr::lint_package()"
# 3. Run all tests (MUST pass 100% - matches workflow)
Rscript -e "devtools::test()"
# 4. Check package (matches workflow - strict CRAN checks)
R CMD build .
R CMD check *.tar.gz --as-cran --no-manual
# 5. Check coverage (MUST meet threshold)
Rscript -e "covr::package_coverage()"
# 6. Build documentation (matches workflow)
Rscript -e "devtools::document()"
# If ANY fails: ❌ DO NOT COMMIT - Fix first!
If ANY of these fail, you MUST fix the issues before committing.
Why This Matters:
styler::style_pkg() locally but dry='on' in CI = failure--as-cran flag = CRAN submission failsstyler for consistent code style.lintr fileExample .lintr:
linters: linters_with_defaults(
line_length_linter(100),
object_name_linter = NULL,
cyclocomp_linter(25)
)
exclusions: list(
"tests/testthat.R"
)
Example roxygen2 documentation:
#' Process Data
#'
#' This function processes input data and returns cleaned results.
#'
#' @param data A data.frame with input data
#' @param threshold Numeric threshold value (default: 0.5)
#' @param verbose Logical; if TRUE, print progress messages
#'
#' @return A data.frame with processed data
#' @export
#'
#' @examples
#' data <- data.frame(x = 1:10, y = rnorm(10))
#' result <- process_data(data, threshold = 0.7)
process_data <- function(data, threshold = 0.5, verbose = FALSE) {
if (!is.data.frame(data)) {
stop("data must be a data.frame")
}
if (verbose) {
message("Processing data...")
}
# Implementation
return(data)
}
/tests/testthat directorytest-*.R for test filesExample test structure:
# tests/testthat/test-process.R
test_that("process_data handles valid input", {
data <- data.frame(x = 1:5, y = 1:5)
result <- process_data(data)
expect_s3_class(result, "data.frame")
expect_equal(nrow(result), 5)
})
test_that("process_data errors on invalid input", {
expect_error(
process_data("not a dataframe"),
"data must be a data.frame"
)
})
test_that("process_data respects threshold parameter", {
data <- data.frame(x = 1:10, y = rnorm(10))
result <- process_data(data, threshold = 0.7)
expect_true(all(result$y >= 0.7 | result$y <= -0.7))
})
yourpackage/
├── DESCRIPTION # Package metadata
├── NAMESPACE # Auto-generated by roxygen2
├── LICENSE # License file
├── README.md # Package overview
├── NEWS.md # Changelog
├── R/
│ ├── package.R # Package-level documentation
│ ├── data.R # Data documentation
│ └── functions.R # Function implementations
├── man/ # Auto-generated documentation
├── tests/
│ ├── testthat.R
│ └── testthat/
│ ├── test-functions.R
│ └── test-data.R
├── data/ # Package data
├── inst/ # Installed files
└── vignettes/ # Long-form documentation
# Load package for development
devtools::load_all()
# Run tests
devtools::test()
# Check package
devtools::check()
# Generate documentation
devtools::document()
# Build package
devtools::build()
# Install locally
devtools::install()
# From CRAN
install.packages("dplyr")
# From GitHub
devtools::install_github("tidyverse/dplyr")
# Specify in DESCRIPTION:
Imports:
dplyr (>= 1.1.0)
Remotes:
github::tidyverse/dplyr@main
stopifnot() or custom validation:: for external functionsT or F (use TRUE and FALSE)attach() or <<- in packageslibrary() inside functionsbrowser() or print() debug codeExample code style:
# ✅ GOOD: Proper function structure
process_data <- function(data, threshold = 0.5) {
# Input validation
stopifnot(
is.data.frame(data),
is.numeric(threshold),
threshold >= 0, threshold <= 1
)
# Use explicit namespace
result <- dplyr::filter(data, value > threshold)
return(result)
}
# ❌ BAD: Poor practices
process_data <- function(data, threshold = 0.5) {
library(dplyr) # DON'T load packages in functions!
attach(data) # NEVER use attach()!
result <- filter(data, value > threshold) # Unclear where filter comes from
result <<- result # DON'T use global assignment!
print(result) # Don't print inside functions
}
Must include GitHub Actions workflows:
Testing (r-test.yml):
Linting (r-lint.yml):
CRAN Check (r-cran.yml):
# 1. Final check
devtools::check(cran = TRUE)
# 2. Build package
devtools::build()
# 3. Submit to CRAN
devtools::submit_cran()
# 4. Respond to CRAN feedback promptly
<!-- R:END -->research
Create structured analyses with numbered findings, execution plans, and task materialization
research
Author a rulebook task spec interactively — research, draft, ask the user clarifying questions, confirm, then create the tasks in rulebook ready for /rulebook-driver. Use when the user wants to plan/spec a feature before implementing.
development
Behavioral guidelines to reduce common LLM coding mistakes — overcomplication, sloppy refactors, hidden assumptions, weak goals. Use when writing, reviewing, or refactoring code. Auto-applies; invoke explicitly via /karpathy-guidelines or 'follow karpathy discipline'.
data-ai
Autonomous AI agent loop for iterative task implementation (@hivehub/rulebook ralph)