R Code Refactoring Prompt Example

Copy or adapt this Markdown prompt when asking an LLM to refactor an R script into the lab template. Refactor code only; do not paste real records, PHI, PII, private paths, credentials, controlled-access data, or sensitive logs into the prompt.

You are an experienced R programmer and code reviewer.

Your task is to reformat the R code below to match the structure, formatting, and annotation style of the provided template. Follow the specific guidelines below and maintain consistency throughout the script.

---

🧾 **Instructions:**

1. **Match the template structure**:
   - Script header with metadata (e.g., title, author, date, description).
   - Library imports and dependency checks.
   - Parameter parsing (using `optparse` if applicable).
   - Main logic clearly separated into well-commented sections.
   - Output saving and final steps.
   - Optional session info at the end (`sessionInfo()`).

2. **Style and formatting guidelines**:
   - Use `message()` for diagnostic progress messages where stderr is appropriate. Preserve `cat()` or `print()` when they produce intended stdout, formatted reports, or returned/displayed results.
   - Preserve stdout/stderr routing, output formatting, return values, and exit status; a logging change must not break a downstream pipe or file consumer.
   - Follow tidyverse-style code conventions (indentation, spacing, line length).
   - Add comments that explain *why*, not just *what* the code is doing.

3. **Behavior and scope**:
   - Preserve the existing input/output contract. Do not add flags, dependencies, filtering rules, new validation failures, or other functional features unless explicitly included in the requested scope.
   - If robustness changes are in scope, check that any system binaries or CLI tools used in the script (via `system()` or `system2()`) are available before running them.
     - Use `Sys.which()` or `nzchar(Sys.which("binary-name"))` for these checks.
     - Exit gracefully with a message if a required binary is missing.
   - Retain existing checks for files, paths, required columns, data types, units, and output directories; propose missing checks separately if adding them would change behavior outside the requested scope.
   - Preserve existing `--verbose` and `--quiet` semantics when present.
   - Keep existing record-count diagnostics auditable without exposing sensitive outputs.
   - Avoid hard-coded absolute paths, credentials, private server names, PHI, PII, controlled-access data examples, or sensitive small-cell outputs.
   - Use schemas or synthetic examples only if an example is needed.
   - Do not request or inspect real data rows; the refactored script should run later in the approved local environment.

4. **Verification expectations**:
   - Identify the narrow smoke test or `testthat` cases that should be run after refactoring, including a comparison of output files, stdout/stderr, and exit status on the same synthetic fixture.
   - If you are operating as a coding agent with command access, run the requested checks and report the command results.
   - If you cannot run tests, leave the script ready for testing and state the commands a human should run outside the code block.

---

📌 **Template code**:
```r
<paste R code template here>
```

📎 **Code to refactor**:
```r
<paste your R code here>
```

---

✍️ **Metadata to include**:
- Script name: <add the script name here or ask the LLM to `Come up with a suitable name`>
- Author: <add your name here>
- Created: <add the date here>

---

✅ **Deliverable**: Return the reformatted R script wrapped in a single code block, followed by a concise verification note if tests or smoke checks could not be run.