agentleFS
Sign inStart free
justanestajustanesta/claude-code-resources/skills/R/developing-packages-r/SKILL.md

developing-packages-r

Skill2 starsChanged 10 months agoMITView on GitHub

Building robust R packages with modern tidyverse patterns. Use this skill when creating or maintaining R packages, designing APIs, choosing dependencies, implementing input validation, writing error messages, or deciding between internal and exported functions. Covers dependency strategy, tidyverse API design patterns, validation approaches, error handling with cli/rlang, testing levels, and documentation priorities.

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 1 is distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use .by for per-operation grouping

    line 42
  2. Very specific:

    Use {{ }} for user-provided columns

    line 43
  3. Very specific:

    Use ... for flexible arguments

    line 44
  4. Distinctive:

    Only used within package

    line 83

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Developing Packages R

This skill covers building robust R packages with modern patterns and best practices.

Dependency Strategy

When to Add Dependencies vs Base R

Add dependency when:

  • Significant functionality gain
  • Maintenance burden reduction
  • User experience improvement
  • Complex implementation (regex, dates, web)

Use base R when:

  • Simple utility functions
  • Package will be widely used (minimize deps)
  • Dependency is large for small benefit
  • Base R solution is straightforward

See dependency-decisions.md for example decisions.

Tidyverse Dependency Guidelines

CategoryPackagesGuidance
Core (usually worth it)dplyr, purrr, stringr, tidyrComplex manipulation, functional programming
Specialized (evaluate carefully)lubridate, forcats, readr, ggplot2Only if heavy usage
Heavy (use sparingly)tidyverse, shinyMeta-package or interactive apps only

API Design Patterns

Modern Tidyverse API

See api-design.md for:

  1. Use .by for per-operation grouping
  2. Use {{ }} for user-provided columns
  3. Use ... for flexible arguments
  4. Return consistent types (tibbles, not data.frames)

Input Validation Strategy

Validation level depends on function type:

Function TypeValidation Level
User-facingComprehensive - check all inputs
InternalMinimal - assume valid, check invariants
vctrs-basedType-stable - automatic checking

See validation-patterns.md for examples.

Error Handling Patterns

Good error messages are:

  • Specific - say what went wrong
  • Actionable - say how to fix it
  • Traceable - include function context

See error-handling.md for:

  • cli package for user-friendly messages
  • rlang for developer tools
  • Including function name in errors

Internal vs Exported Functions

Export Function When:

  • Users will call it directly
  • Other packages might want to extend it
  • Part of the core package functionality
  • Stable API that won't change often

Keep Function Internal When:

  • Implementation detail that may change
  • Only used within package
  • Complex implementation helpers
  • Would clutter user-facing API

See internal-vs-exported.md for examples.

Testing Strategy

Testing Levels

LevelPurposeExample
Unit testsIndividual functionsEdge cases, error handling
Integration testsWorkflow combinationsEnd-to-end pipelines
Property-based testsInvariantsFunction properties hold

See testing-patterns.md for examples.

Documentation Priorities

Must Document:

  • All exported functions
  • Complex algorithms or formulas
  • Non-obvious parameter interactions
  • Examples of typical usage

Can Skip Documentation:

  • Simple internal helpers
  • Obvious parameter meanings
  • Functions that just call other functions

source: Sarah Johnson's gist https://gist.github.com/sj-io/3828d64d0969f2a0f05297e59e6c15ad

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free