r-best-practice
Files
SKILL.mdagentsreferences
Install
Install the containing plugin
/plugin install software-design@llm-skills
Invoke this skill after installation
/software-design:r-best-practice
This skill is bundled inside software-design. Install the plugin once, then Claude Code can use any of its included skills. Browse the full plugin repository at github.com/alisonaquinas/llm-software-design.
SKILL.md
name: r-best-practice description: > review r code and planning work against common r conventions for formatting, naming, structure, testing, and tooling. use when the user asks for idiomatic r, r code review, r refactoring guidance, r project structure, or r tooling such as styler, lintr, testthat, or tidyverse conventions.
R Best Practice
Use this skill to review or improve R work using common ecosystem conventions instead of ad hoc local habits.
Intent Router
| Need | Load |
|---|---|
| core conventions, tooling defaults, and review checklist for R | references/best-practices.md |
Quick Start
- Confirm the target version, dialect, runtime, framework, or vendor before recommending changes.
- Prefer existing project conventions when they are already enforced and internally consistent.
- Apply the default guidance in
references/best-practices.mdfor naming, structure, testing, and tooling. - Recommend the smallest change set that improves clarity, safety, and maintainability.
Workflow
- Identify the runtime, dialect, or host environment before making specific recommendations.
- Separate language-level guidance from framework-, vendor-, or platform-specific conventions.
- Prioritize correctness, readability, changeability, and operability before micro-optimizations.
- Note the automation path: formatter, linter, type checker, compiler flags, or test runner.
- Call out the highest-leverage refactors first instead of producing style-only churn.
Typical Focus Areas
- naming, layout, and public API clarity
- boundary handling, state management, and error paths
- dependency direction, module structure, and test seams
- tooling, CI checks, and repeatable local verification
- performance, portability, or safety constraints only when they materially affect the design
Outputs to Prefer
- summarize the governing constraints before detailed recommendations
- group findings by severity, maintenance impact, or migration effort
- recommend concrete edits, checks, or follow-up tests
- preserve externally visible behavior unless the request explicitly allows semantic changes
Common Requests
Review this R module for idiomatic structure, naming, boundary handling, and test gaps.
Refactor this R snippet to follow common R best practice without changing behavior.
Verification and Follow-Through
- verify the recommendation with the formatter, linter, compiler, or test command named in
references/best-practices.md - call out which behavior must remain unchanged before suggesting stylistic cleanup
- recommend one or two concrete checks that prove the refactor improved clarity, safety, or maintainability
- preserve enforced repository conventions when they intentionally differ from the default baseline
Recovery Cues
- if the runtime, dialect, framework, or vendor is unknown, give the safest default and name the missing fact that would narrow the advice
- if project automation already enforces a competing convention, follow the enforced rule and explain the exception
- if correctness bugs and style issues are mixed together, fix correctness and observability first, then return to style
Safety Notes
- do not force ecosystem migration unless the current stack is clearly blocking maintainability
- avoid style-only churn in legacy code that is otherwise stable
- preserve externally visible behavior unless the user asks for breaking changes