r-package-check skill
Run the full R package release gate — regenerate docs, run the test suite, run R CMD check --as-cran, and triage every ERROR / WARNING / NOTE against CRAN policy before a release or submission. Use when the user says "check my R package", "R CMD check", "is this package CRAN-ready", "run devtools::check", "prepare for CRAN submission", or points at a directory containing a DESCRIPTION file. Produces a check report + CRAN-submission checklist in `quality_reports/`.
Is the r-package-check skill safe?
Clean: nothing in its files matched our rules. We read 1 file in the folder on 2026-09-28.
No findings.
Install the r-package-check skill
A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.
git clone --depth 1 https://github.com/pedrohcgs/claude-code-my-workflow.git /tmp/claude-code-my-workflow mkdir -p ~/.claude/skills cp -r /tmp/claude-code-my-workflow/.claude/skills/r-package-check ~/.claude/skills/r-package-check
In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub
The instructions your agent would load
SKILL.md as published, without the frontmatter. Read it on GitHub
/r-package-check — R Package Release Gate
Run the document → test → check → triage pipeline that decides whether an R package is releasable, then review the source for the issues R CMD check cannot see.
Input: $ARGUMENTS — the package root (a directory containing DESCRIPTION). If blank, autodetect by searching upward/within the working directory for DESCRIPTION.
Constraints
- Follow .claude/rules/r-package-conventions.md — the CRAN-readiness bar (0 errors, 0 warnings, explained notes) is the gate.
- Treat man/ and NAMESPACE as generated — regenerate with devtools::document(); never hand-edit them.
- Run the r-package-reviewer agent on the source before declaring the package releasable.
- Do not bump the version or write to CRAN. This skill checks; the human decides when to submit.
Workflow Phases
Phase 0: Pre-Flight Report
## Pre-Flight Report — R Package Check
**Package:** [name + version from DESCRIPTION]
**Root:** [path]
**Exported functions:** [from NAMESPACE / `@export` count]
**Dependencies:** Imports [list] · Suggests [list] · Depends [list]
**Toolchain available:** devtools [✓/✗], roxygen2 [✓/✗], testthat [✓/✗], R CMD [✓/✗], covr [✓/✗]
**Plan:** document → test → check --as-cran → triage → reviewDetect the toolchain with a quick probe; if devtools/R CMD is missing, stop and tell the user what to install.
Rscript -e 'cat("devtools:", requireNamespace("devtools", quietly=TRUE),
"roxygen2:", requireNamespace("roxygen2", quietly=TRUE),
"testthat:", requireNamespace("testthat", quietly=TRUE),
"covr:", requireNamespace("covr", quietly=TRUE), "\n")'Phase 1: Document
Regenerate man/ + NAMESPACE and detect drift (generated docs that were not committed):
Rscript -e 'devtools::document("[pkg]")'
git -C "[pkg]" status --short man/ NAMESPACE # any diff = generated docs were staleIf git status shows changes, flag: the committed man//NAMESPACE were out of sync with the roxygen blocks.
Phase 2: Test
Rscript -e 'devtools::test("[pkg]")'Report failures and (if covr is available, Phase 4) coverage of exported functions.
Phase 3: Check (--as-cran)
Run the full check. This is slow (minutes) — background-launch and stream with the Monitor tool rather than blocking:
Rscript -e 'devtools::check("[pkg]", args = "--as-cran")'
# or: R CMD build [pkg] && R CMD check --as-cran [pkg]_*.tar.gzThen triage every result into a table:
- ERROR / WARNING → must fix before submission.
- NOTE → fix if cheap; otherwise write the justification you'd put in cran-comments.md (e.g., "New submission", "Found the following (possibly) invalid URLs … the URL is correct and reachable").
Phase 4: Coverage (optional)
Rscript -e 'covr::package_coverage("[pkg]")'Report per-function coverage; flag exported functions with 0% coverage.
Phase 5: Source Review
Delegate to the r-package-reviewer agent:
"Review the package source at [pkg]"The agent is read-only and returns its report; save it to qualityreports/[pkg]package_review.md. Address Critical (CRAN-policy violations) and High (check WARNINGs) findings.
Phase 6: Release Gate + Report
Save a report to qualityreports/[package]package_check.md and present a verdict:
## Release Gate — [package] [version]
- R CMD check --as-cran: E errors, W warnings, N notes
- Tests: P passed, F failed
- Coverage: X% of exported functions
- r-package-reviewer: C critical, H high
- **Verdict:** RELEASABLE / FIX-FIRST / POLICY-VIOLATION
### CRAN-submission checklist
[ ] 0 errors, 0 warnings; each note justified in cran-comments.md
[ ] Version bumped + NEWS.md updated
[ ] devtools::check_win_devel() / R-hub on other platforms (note: run separately)
[ ] Reverse-dependency check if this is an update (revdepcheck)Important
- --as-cran or it doesn't count. A plain R CMD check misses the policy checks that actually gate submission.
- Generated files are generated. If docs drift, the fix is devtools::document(), not editing .Rd.
- The gate is 0/0/explained. 0 errors, 0 warnings, every remaining note justified — nothing less is "CRAN-ready."
- This skill does not submit. Cross-platform checks (win-devel, R-hub) and the actual devtools::release() are the maintainer's call.
Long-running checks: use the Monitor tool
R CMD check --as-cran and covr can run for several minutes. Don't block on them, and don't poll with sleep: start the Monitor tool with a command that runs the check itself, tees the full output to a log, and prints only the lines you would act on, e.g. Rscript -e 'devtools::check("[pkg]", args = "--as-cran")' 2>&1 | tee qualityreports/r-package-check.log | grep --line-buffered -E 'ERROR|WARNING|NOTE|Status:|[Ee]rror'. The watch ends when the check exits; set timeoutms above the default 5 minutes (max 3600000). The filter must match failure as well as success, because silence looks the same as "still running". If you only need one notice when the check finishes, run it with Bash runinbackground: true instead and read the log when the job reports its exit. Monitor has no job-id parameter, so it cannot attach to a job already running in the background; see data-analysis/SKILL.md for the log-and-tail variant.
More skills from pedrohcgs/claude-code-my-workflow
- Aadjudicate-reviewTurn an incoming set of findings — from an AI reviewer, a referee report, a code review, a linter, or a second model — into verified fixes, without letting a confident misread damage correct work. Every finding is a CANDIDATE until checked against the actual source. Use whenever you receive review comments, audit findings, or a critique you did not write yourself, especially when the reviewer is a model or when the volume is too large to check by feel.
- Aaudit-reproducibilityEnforce the replication-protocol.md rule by cross-checking numeric claims in a manuscript against the actual R / Stata / Python outputs. Report PASS/FAIL per claim against tolerance thresholds. Use before submission and before releasing a replication package.
- Ablast-radiusBefore and after changing anything shared — a function's return value, a signature, a schema, a label set, a config default, a constant, a file format — find every consumer and actually run them. Catches the change that looks purely additive but silently breaks a contract in a file you never opened. Use when editing shared code, adding a field/column/return element, renaming, changing units or defaults, or touching a pipeline that produces reported numbers.
- Acapture-environmentSnapshot the computational environment for a replication package — detects the analysis stack (R / Stata / Python) and emits the right lockfiles (renv.lock + sessionInfo.txt, requirements.txt / environment.yml / uv.lock, Stata version + ado package list), records seeds and RNG kind, optionally writes a pinning Dockerfile, and produces a paste-ready "Computational requirements" block. Use when user says "capture the environment", "snapshot my dependencies", "pin the versions", "make a renv.lock / requirements.txt", "make this byte-reproducible", or before releasing a replication package to openICPSR / the AEA Data Editor.
- AchallengeStress-test a finding against the choices you did not make. Enumerates the discrete forks a competent analyst could have taken (measure definition, sample filter, control set, clustering level, weighting, functional form), runs the specification grid, and reports the distribution rather than a point estimate — then attacks the identifying assumption with named, computable sensitivity statistics. Use when the user says "is this robust", "challenge this result", "specification curve", "multiverse", "how sensitive is this", "what if I'd used a different measure", "stress-test my estimate", or before a result becomes a headline claim. NOT a reviewer of prose or code — it challenges the CLAIM.
- AcheckpointSave a structured state snapshot before stopping or handing off. Captures the active plan, recent decisions, file pointers (with line numbers), open questions, and the next 1–3 actions into a checkpoint file under `quality_reports/checkpoints/`. Optionally proposes `[LEARN]` entries to add to MEMORY.md. Use when user says "checkpoint", "save state", "snapshot before I stop", "where am I", "wrap up the session for handoff", or before a long break / model switch / collaborator handoff. Companion to (NOT replacement for) the narrative session-log workflow.
- Acoauthor-briefGenerate a co-author / collaborator handoff brief for a multi-author, multi-machine project — summarizing what changed since the last brief (git delta), the current state of each artifact (manuscript, analysis, slides), open questions, how to reproduce locally, and any restricted-data access steps. Use when user says "coauthor brief", "handoff brief", "bring my coauthor up to speed", "what changed since last week", "onboard a collaborator", "write a handoff for [name]", or before sending a co-author the repo. NOT a commit or a checkpoint — it is the cross-machine, cross-person summary `meta-governance.md` only partially covers.
- AcommitCommit the current work — runs the quality, consistency and passport gates, branches off main if needed, stages specific files, and writes a commit whose subject states what is now true. Pushes and opens a pull request only with --pr or when the user asks; never merges — a merge happens only when the user explicitly says to merge. Use ONLY on explicit commit intent — user says "commit", "let's commit this", "open a PR", or prefixes with `/commit`. Do NOT auto-invoke on vague end-of-task phrases ("we're done", "wrap up") — those require explicit confirmation first. Never force-pushes or skips hooks.
- Acompile-latexCompile a Beamer LaTeX slide deck with XeLaTeX (3 passes + bibtex). Use when user says "compile", "build the slides", "rebuild the PDF", "run latex", "render the tex", or asks why a `.tex` file isn't producing a PDF. Operates on `Slides/*.tex`.
- Acompress-sessionDistill the current conversation into a structured note (decisions made, open questions, file pointers with line numbers, next 1–3 actions) and save to `quality_reports/session_logs/` before auto-compression. Differs from `/checkpoint` (explicit stop-point snapshot) and from auto-compaction (which truncates rather than distills). Use when context is approaching auto-compact threshold, when a long pipeline has accumulated many decisions, or when the user says "compress", "distil this session", "before we hit auto-compact", "structured handoff before context resets".
- Acontext-statusShow current context status and session health. Use to check how much context has been used, whether auto-compact is approaching, and what state will be preserved.
- Acreate-lectureCreate a new Beamer lecture `.tex` from source papers and materials, with notation consistency checks and the project's preamble wired in. Use when user says "create a lecture on X", "new lecture from these papers", "start a deck on topic Y", "scaffold a new Beamer file", "build me a lecture from these PDFs". Scaffolds the full deck — NOT for compiling existing `.tex` (use `/compile-latex`).