init-r-workspace

name	init-r-workspace
description	Bootstrap a local R analysis workspace with standard files, folders, local .claude/skills, and an optional renv layer. Use when starting a new R project or analysis workspace.
argument-hint	["target-directory"]
disable-model-invocation	true

Init R Workspace

Goal

Create a consistent local workspace starter layout for R analysis projects.

Required Workspace Structure

Create these paths in the target workspace root:

• main.R
• src/
• test/
• .here
• LOG.md
• data/
• .claude/skills/

Testing Convention

• Use test/ to hold testthat tests for functions created by either the user or the assistant.
• Keep one testthat file per function.
• Default naming: test/test-<function_name>.R.

Main Script Template

Write main.R with this exact starter content:

here::i_am("main.R")

library(here)
library(tidyverse)
library(lubridate)
library(stringr)

source(here('src', ""))

R Pipe Standard

• For any R code created or edited while using this skill, always use the base R pipe |> instead of %>%.

Reproducible environment layer with renv

• When the workspace should be collaboration-ready, rerunnable on another machine, or stable across longer-lived analysis/report cycles, add a project-local renv layer after the base scaffold exists.
• Current renv::init() documentation says initialization discovers project dependencies with dependencies(), installs them into the project library, creates a lockfile, and wires the project so later sessions autoload the environment.
• Keep renv::snapshot() for deliberate dependency changes, renv::restore() for fresh machines or CI rebuilds, and renv::status() as the fast drift check before handoff or major reruns. Current renv docs explicitly recommend resolving status() issues before further work.
• For analysis workspaces, the default implicit snapshot posture is usually a good fit because it follows packages actually discovered in scripts, reports, and app files. If the workspace later becomes package-centric, revisit the snapshot type deliberately.
• Keep renv.lock under version control alongside the analysis scripts, report files, and pipeline files that depend on it.
• If the same repository needs materially different dependency sets for development versus a Shiny runtime or another operational mode, renv project profiles can separate those paths. Keep profile count small unless the distinction is genuinely operationally important.
• renv captures the R package library state. When operating-system libraries, compiler toolchains, or other system-level dependencies also need to stay stable, pair the project with a container or other system-level environment contract.

Resources

• references/renv-project-setup.md

AGENTS.md Handling

• Do not create a local AGENTS.md during scaffolding unless the user explicitly requests it.

Optional companion skills

If your broader Claude setup also includes separate workspace-management, skill-installation, or test-policy skills, use those for deeper log policy, workspace maintenance, or generic test discipline instead of expanding this skill.

Keep this skill focused on R workspace bootstrapping.

Safety Rules

• Do not overwrite existing files unless the user explicitly asks.
• If a path already exists, keep it and only create missing components.
• Summarize which paths were created vs already present.