ropensci-skills

Actually CARRY OUT an AI-assisted rOpenSci review pass on a package working tree and produce a transparent, reproducible report — as opposed to just providing review context. Use this when someone says "run the review", "audit this package's tests / dependencies / complexity / performance", "produce a review report", or wants an evidence-backed write-up they can attach to a `ropensci/software-review` issue. This skill DRIVES the work and emits a report; the sibling `package-review` skill supplies the reviewer checklist and "what to evaluate" context that this skill reads to decide what to check. For a human deciding *how* to review, use `package-review`; to make an agent *do* a review and report on it, use this.

Actually CARRY OUT an AI-assisted code-complexity analysis of an R package and produce a transparent, reproducible report. Use this when someone says "analyse the complexity of this package", "which functions are too complex / could be simplified", "find the god-functions", "where's the duplication", or wants an evidence-backed simplification write-up for an rOpenSci review. This DRIVES the analysis (measures complexity per function, builds a static call-graph, confirms findings with runtime probes) and emits a report; it does not refactor the package. It is the code-complexity pass of a review — one of the `run-*` review-runner skills. For the reviewer checklist and the other passes, see `package-review` / `run-package-review`.

Actually CARRY OUT an AI-assisted dependency analysis of an R package and produce a transparent, reproducible report. Use this when someone says "review the dependencies", "which dependencies could we drop", "can base R replace this import", "is this dependency worth it", or wants an evidence-backed dependency write-up for an rOpenSci review. This DRIVES the analysis (walks the recursive dependency tree, separates prunable leaves from pinned packages, counts real usage, checks base-R feasibility) and emits a report; it does not edit the package. It is the dependency pass of a review — one of the `run-*` review-runner skills. For the reviewer checklist and the other passes, see `package-review` / `run-package-review`.

Actually CARRY OUT an AI-assisted performance and memory analysis of an R package and produce a transparent, reproducible report. Use this when someone says "review the performance", "is this memory-safe on large inputs", "where are the hot paths", "does this scale", "will this OOM", or wants an evidence-backed performance write-up for an rOpenSci review. This DRIVES the analysis (traces the hot path, measures real anchors, extrapolates to large inputs, identifies risks) and emits a report; it does not edit the package. It is the performance pass of a review — one of the `run-*` review-runner skills. For the reviewer checklist and the other passes, see `package-review` / `run-package-review`.

Actually CARRY OUT an AI-assisted audit of an R package's test suite and produce a transparent, reproducible report. Use this when someone says "audit the tests", "review the test suite", "how good are these tests", "are the tests actually testing anything", or wants an evidence-backed test-quality write-up for an rOpenSci review. This DRIVES the audit (reads the tests and the code, runs the suite for real, measures coverage depth, hunts flakiness) and emits a report; it does not fix or add tests. It is the test-suite pass of a review — one of the `run-*` review-runner skills. For the reviewer checklist and the other passes, see `package-review` / `run-package-review`.

Help an author write and submit a post to the rOpenSci blog (a long-form blog post or a shorter tech note) following the rOpenSci Blog Guide (blogguide.ropensci.org). Use this whenever someone wants to write an rOpenSci blog post or tech note, announce a package on the rOpenSci blog, draft the index.Rmd/index.qmd for roweb3, set up the YAML frontmatter or author metadata, add alt text / images correctly, run the roblog checks, or follow the blog-submission PR workflow. Triggers on "write an rOpenSci blog post", "tech note", "blog about my package release", "submit a post to roweb3", or "rOpenSci blog YAML". For the package release mechanics themselves use package-release.

Help maintain an rOpenSci R package over its lifetime per the Developer Guide's "Maintaining Packages" chapters. Use this whenever someone is setting up collaboration/community files (CONTRIBUTING, code of conduct), grooming a GitHub repo (topics, .gitattributes, labels), changing or taking over a package maintainer, deprecating or renaming functions/arguments/datasets/packages, managing the package lifecycle, or archiving a package. Triggers on phrases like "add a contributing guide", "set up code of conduct", "deprecate this function", "rename this package", "I'm taking over maintenance", "archive this package", or "make my repo more discoverable". For cutting a release use package-release; for initial package standards use package-standards.

Guide an R package maintainer through releasing a new version the rOpenSci way — updating NEWS.md, choosing a semantic version, running the CRAN release checks, tagging the release, writing GitHub release notes, and announcing it. Use this whenever someone is about to release/ship a package version, asks "how do I release this to CRAN", "bump the version", "write the NEWS file", "do a GitHub release", "what's the release checklist", or wants to announce/market a release. Built on the rOpenSci Developer Guide "Releasing" and "Marketing" chapters. For ongoing maintenance, lifecycle/deprecation, and archiving use package-maintenance; for a release blog post use blog-post.

Help a reviewer (or editor) conduct an rOpenSci software peer review of an R package. Use this whenever someone has agreed to review a package for rOpenSci, asks "how do I review this package", wants the rOpenSci reviewer checklist / review template, needs to evaluate a package's docs/tests/code/UX for review, or is an editor doing initial editor checks. Covers the official reviewer checklist and template, what to evaluate beyond the checkboxes, reviewer conduct and timing, the pkgreviewr tooling, and the editor checks. This is for people REVIEWING a package; authors preparing to submit should use peer-review-author instead.

Build or audit an R package so it meets rOpenSci's package development standards from the rOpenSci Developer Guide (devguide.ropensci.org). Use this whenever someone is writing, reviewing, refactoring, or preparing an R package and wants it to follow rOpenSci / tidyverse best practices — even if they only say "make my package better", "is this package up to standard", "set up CI", "fix my DESCRIPTION", "add roxygen docs", or "get this ready for CRAN/rOpenSci". Covers package naming, DESCRIPTION and Authors@R, dependency choices, roxygen2 documentation, README, testing and coverage, code style, continuous integration, and security. This is the foundation skill; the peer-review, stats-standards, release, and maintenance skills build on it.

Guide an R package author through preparing for and submitting to rOpenSci software peer review (the ropensci/software-review process). Use this whenever someone wants to submit a package to rOpenSci, asks "is my package in scope", "am I ready to submit to rOpenSci", "what does the submission need", how to fill in the submission issue, how to run pkgcheck before submitting, or how the @ropensci-review-bot and the review process work from the author's side. Covers the scope/fit and overlap policy, the pre-submission checklist, running pkgcheck, the submission template, and what to expect during review. For making the package itself compliant, pair with package-standards; for statistical packages also use stats-standards.

Help authors and reviewers apply rOpenSci's Statistical Software peer review standards (stats-devguide.ropensci.org) to a statistical R package. Use this whenever a package implements a statistical method, model, or algorithm (Bayesian, regression, machine learning, EDA/summary stats, time series, spatial, dimensionality reduction/clustering, probability distributions) and someone wants to comply with or review against the rOpenSci statistical standards, document standards with the srr package (@srrstats tags), run srr or autotest, or understand the graded badges. This is an EXTENSION of the general rOpenSci process — always apply package-standards first; this skill adds the statistical standards on top.