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.