r-advanced

name	r-advanced
description	Advanced R and R Shiny implementation patterns for reactivity, module testing, data engineering, analyst workbenches, and reusable modeling or reporting helpers. Use for recurring implementation pain points.

R Advanced

Turn recurring R and Shiny friction into reusable implementation patterns grounded in commit history, tests, logs, and current package documentation.

Quick start

1. If the task starts from a repository, run scripts/r_repo_commit_scan.py <repo-path>.
2. Read references/evidence-map.md first.
3. Load only the narrowest reference that matches the current problem:
   • references/shiny-reactivity-ui-state.md
   • references/model-builders-and-tidy-results.md
   • references/publication-tables-and-formatting.md
   • references/gtsummary-recurring-edge-cases.md
   • references/data-registry-and-relational-guards.md
   • references/hierarchy-maps-and-joined-datasets.md
   • references/arrow-parquet-large-data-doctrine.md
4. Keep reusable logic in src/ helpers, keep Shiny modules thin, and add paired tests in test/.
5. When a repo task will end in commits or PR work, update the repo’s changelog/version-history surface before the Git step.
6. If the task is narrow, prefer the split global skills:
   • /r-shiny-debugging
   • /r-model-builder
   • /r-tables-reporting
   • /r-data-validation
   • /r-package-dev
   • /r-shiny
   • /r-eda
   • /r-stats

Workflow

1. Extract evidence

• Summarize R/Shiny churn from commits, tests, changelog entries, and workspace logs.
• Prefer concrete evidence: commit subjects, repeatedly changed files, new tests, recurring warning-handling code, UI-state fixes, repeated table post-processing blocks.
• Treat any recommendation as ungrounded until it points back to that evidence.

2. Match the evidence to a narrow topic

• Repeated mod_*.R, app.R, reactiveVal, updateSelectizeInput, or testServer changes point to Shiny state-management work.
• Repeated model-helper, broom, survival, lme4, or performance code points to programmatic model-builder work.
• Repeated gtsummary, flextable, digits, p-value, CI, row nesting, or label rewrites point to publication-output work.
• Repeated registry, ingest, join, key, hierarchy, or coercion code points to data-engineering and relational-guard work.
• Repeated hierarchy-slot UX, dataset-map, graph-layout, inspector, or joined-dataset creation code points to hierarchy-aware workbench design.
• Repeated giant CSV intake, multi-file ingest, memory-pressure workarounds, or repeated re-reads of the same source point to Arrow/Parquet working-layer design.

3. Apply the stored patterns

• Reuse the smallest proven pattern that fits the task.
• Add validation close to the failure point: validate(need()), parser problem checks, stale-state signatures, or explicit join contracts.
• Keep recommendation helpers pure and deterministic so tests can pin them down.
• When post-processing gtsummary objects, keep row surgery explicit and testable.
• For large or repeatedly queried analytical data, prefer an early Parquet working layer, keep Arrow pipelines lazy, and delay collect() until the slice is small.

4. Save new lessons back into the skill

Update this skill when work reveals one of these signals:

• the same fix appears in more than one commit or workspace log entry;
• a helper needed non-obvious package behavior from current docs;
• a failure was easy to miss until UI QA or tests exposed it;
• a compact snippet or checklist would clearly accelerate future R/Shiny work.

Add the new lesson to the narrowest reference file and extend the evidence map.

Built-in resources

Repo evidence

• references/evidence-map.md stores the evidence-grounded topic map used to build this skill.

Shiny state and UI patterns

• references/shiny-reactivity-ui-state.md covers selectize hydration, stale-result state, event gating, module structure, plot-control validation, and module testing.

Model builders and tidy results

• references/model-builders-and-tidy-results.md covers formula construction, model-family wrappers, warning surfacing, broom/performance output, and registry-driven recommendation helpers.

Publication outputs

• references/publication-tables-and-formatting.md covers gtsummary, p-values, labels, dichotomous handling, and flextable export.
• references/gtsummary-recurring-edge-cases.md covers the repeated edge cases seen in repeated clinician-facing table work and consultation analyses.

Registry and relational guards

• references/data-registry-and-relational-guards.md covers type inference, readr::type_convert(), hierarchical IDs, and guarded joins with dplyr.
• references/hierarchy-maps-and-joined-datasets.md covers visible hierarchy-slot controls, dataset grain profiles, draggable relationship maps, join previews, joined-dataset registry carry-forward, and module-test patterns for stateful analytical workbenches.

Large-data Arrow/Parquet doctrine

• references/arrow-parquet-large-data-doctrine.md covers when to create a Parquet working layer, how to keep Arrow pipelines lazy, partitioning/file-layout guardrails, and when to hand off to /r-eda.

Script

• scripts/r_repo_commit_scan.py is bundled with this skill and produces a quick repo-level R/Shiny churn summary to seed future evidence maps.