npx skills add smithery/jeremy-allen --skill developing-packages-r
jeremy-allen/claude-skills · Archived
developing-packages-r
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.
Installation
npx skills add jeremy-allen/claude-skills --skill developing-packages-r
Stronger alternatives
This repository is archived — consider an actively maintained alternative.
Modern tidyverse patterns, style guide, and migration guidance for R development. Use this skil…
34 installsR performance profiling, benchmarking, and optimization strategies. Use this skill when code is…
14 installsTidy evaluation and programmatic tidyverse patterns using rlang. Use this skill when writing fu…
12 installsObject-oriented programming in R: S7, S3, S4, and vctrs class design. Use this skill when desig…
11 installsSimilar popular skills
Related neighbors and high-traction skills in the same topics — useful to compare before installing.
MANDATORY for Flink or Amazon Managed Service for Apache Flink (MSF) questions. You MUST activa…
3.4K installsUse for ALL Streamlit tasks: creating, editing, debugging, beautifying, styling, theming, optim…
2.9K installsAlso in this package
Other skills from jeremy-allen/claude-skills.
npx skills add jeremy-allen/claude-skills
More details
Agent compatibility
Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.
Also listed on
Alternate registries and mirrors of this skill.
Repository health
main
Package contents
Files included with this skill beyond the listing page.
-
skill md
SKILL.md3,724 B -
docs
SUMMARY.md449 B
History
- First seen on skills.sh
- First recorded snapshot · 14 installs
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](references/dependency-decisions.md) for example decisions.
Tidyverse Dependency Guidelines
| Category | Packages | Guidance |
|---|---|---|
| Core (usually worth it) | dplyr, purrr, stringr, tidyr | Complex manipulation, functional programming |
| Specialized (evaluate carefully) | lubridate, forcats, readr, ggplot2 | Only if heavy usage |
| Heavy (use sparingly) | tidyverse, shiny | Meta-package or interactive apps only |
API Design Patterns
Modern Tidyverse API
See [api-design.md](references/api-design.md) for:
- Use
.byfor per-operation grouping - Use
{{ }}for user-provided columns - Use
...for flexible arguments - Return consistent types (tibbles, not data.frames)
Input Validation Strategy
Validation level depends on function type:
| Function Type | Validation Level |
|---|---|
| User-facing | Comprehensive - check all inputs |
| Internal | Minimal - assume valid, check invariants |
| vctrs-based | Type-stable - automatic checking |
See [validation-patterns.md](references/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](references/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](references/internal-vs-exported.md) for examples.
Testing Strategy
Testing Levels
| Level | Purpose | Example |
|---|---|---|
| Unit tests | Individual functions | Edge cases, error handling |
| Integration tests | Workflow combinations | End-to-end pipelines |
| Property-based tests | Invariants | Function properties hold |
See [testing-patterns.md](references/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