r-xla-prepare-pr

name	r-xla-prepare-pr
description	Prepare an R package for a pull request. Use when the user says "prepare pr", "get this ready for review", "run the checks", or wants to finalize changes before opening a PR. Must be run from inside the package directory (contains a DESCRIPTION file).
user_invocable	true
tools	Read, Edit, Glob, Grep, Bash, Write, AskUserQuestion, Skill

Prepare R Package PR

Run all quality checks, fix issues, update documentation and metadata, then create a PR using the /pr-create skill.

Step 1: Regenerate Documentation

devtools::document()

This regenerates NAMESPACE, .Rd files, and collation order. Must run before testing since new exports/generics require an updated NAMESPACE.

Step 2: Lint

jarl check --fix .

Fix any remaining errors that --fix cannot handle automatically.

Step 3: Test

devtools::test()

If specific tests fail, re-run only those:

testthat::test_file("tests/testthat/test-<name>.R")

Fix bugs until all tests pass.

Step 4: R CMD check

devtools::check()

Fix failures. If documentation errors appear, re-run devtools::document() and check again. Repeat until clean.

Step 5: Format

If a Makefile exists in the package root:

make format

Otherwise, format R files with air:

air format .

Step 6: Review AGENTS.md

Read the package's AGENTS.md. If the changes involved renames, structural changes, or core design modifications, update the relevant sections. Also update internal design documents (e.g., design vignettes) if affected.

Step 7: Check Documentation Completeness

Review the changes and verify:

• Roxygen: Are new/changed functions properly documented with #' comments?
• Environment variables / options: If new Sys.getenv() or getOption() calls were added, update the @section Environment Variables: and @section Options: sections in R/package.R.
• README.Rmd: If README.Rmd was modified, rebuild:

  devtools::install()
  devtools::build_readme()
  

  Never edit README.md directly.
• Major features: For significant new functionality, check that user-facing documentation (vignettes, function help pages) is adequate.

Step 8: Update NEWS.md

If user-facing changes were made (new features, bug fixes, behaviour changes), add entries to NEWS.md under the development version heading (# <package> (development version)).

Skip for purely internal changes (refactoring, CI, code style).

Step 9: Update _pkgdown.yml

Check that all new exported functions appear in the correct category in _pkgdown.yml. Add any missing entries.

Step 10: Bump Dev Version

Increment the fourth component of the development version in DESCRIPTION:

0.1.0      -> 0.1.0.9000
0.1.0.9000 -> 0.1.0.9001
0.1.0.9001 -> 0.1.0.9002
1.2.3.9005 -> 1.2.3.9006

Use the Edit tool on the Version: field.

Step 11: Create PR

Use the /pr-create skill to create the pull request, monitor CI, and fix any failures.

Important Rules

1. Never edit .Rd files -- they are generated by roxygen2
2. Never edit README.md -- it is generated from README.Rmd
3. Run devtools::document() before testing -- NAMESPACE must be current
4. Use /pr-create for PR creation -- don't reinvent CI monitoring
5. Fix issues at each step before moving on -- don't accumulate failures