| name | r-skill-family |
| description | Coordinate the R skill family by routing new topics to the right r-* skills, researching current primary sources, and updating only the skills that need new doctrine. Use when expanding or propagating R skill guidance. |
| argument-hint | ["topic or package"] |
| disable-model-invocation | true |
R Skill Family
Treat the global R skills as one coordinated family. Route the topic first, research second, and update only the skills that genuinely need new doctrine.
Quick start
- Read
references/skill-routing-map.md.
- Read
references/update-scope-patterns.md.
- List the requested topics, packages, functions, file types, and concrete user goals.
- Classify each topic's R involvement:
- core R;
- R package workflow;
- Shiny/app work;
- modeling/statistics;
- tables/reporting;
- validation/data quality;
- EDA/data engineering;
- R-adjacent or intersection with R.
- Rank the affected global
r-* skills from most to least relevant.
- Research current primary sources for the topic.
- Update the implicated skills in rank order, starting with the one that should hold the deepest doctrine.
- Validate every changed skill and record the work in the local workspace log when applicable.
Workflow
1. Identify requested topics and packages
- Extract the exact package names, functions, data formats, app surfaces, or workflow phases the user cares about.
- Split bundled requests into narrower topics when the routing differs.
- Preserve concrete nouns from the request so later updates stay specific.
2. Determine R involvement and the intersection with R
- Treat a topic as core R when it directly changes R code, R workflows, package behavior, or analyst-facing R practice.
- Treat a topic as R-adjacent when the underlying system is not purely R but materially changes how R work is built or run, such as Arrow/Parquet, GitHub Actions for R packages, databases queried from R, or JavaScript widgets inside Shiny.
- At the intersection, update the R-facing contract rather than trying to absorb the whole non-R domain into the R skills.
- If R is only incidental, do not force the topic across multiple R skills.
3. Rank the involved global R skills
- Use
references/skill-routing-map.md to rank the skills from deepest doctrine holder to lightest downstream consumer.
- Start with the skill that should own the densest reusable guidance.
- Then update only the downstream skills that need routing notes, quick-start hooks, or narrower cross-skill references.
- Stop when additional edits would add only generic noise.
4. Research before editing
- Prefer official package sites, Posit docs, package vignettes, CRAN manuals, and other primary sources.
- For packages, APIs, and frameworks that may have changed recently, verify current behavior before writing doctrine.
- Save only reusable lessons, recurring failure patterns, and non-obvious package behavior.
- Mark inferences clearly when an update extends beyond direct repo evidence.
5. Update skills from most to least relevant
- Put the densest guidance in the most relevant skill.
- Prefer adding a narrow reference file over bloating
SKILL.md.
- Add lighter coordination notes to secondary skills when they need to hand off, consume, or debug the same topic.
- Keep cross-skill language consistent so the family routes cleanly.
6. Validate and record the work
- Re-check each changed skill for valid YAML frontmatter, a clear description, working file references, and a
SKILL.md entrypoint.
- Keep the
SKILL.md frontmatter and instructions aligned whenever the skill meaning changes.
- Update the local
LOG.md when working inside a workspace that tracks changes.
- Summarize which skills changed, why they changed, and which sources informed the update.
Current global R skill family
Primary r-* global skills:
/r-advanced/r-data-validation/r-eda/r-model-builder/r-package-dev/r-shiny/r-shiny-debugging/r-skill-family/r-stats/r-tables-reporting
Companion R-adjacent surfaces:
Resources
references/skill-routing-map.mdreferences/update-scope-patterns.md
