Coding Prompt for R Script

Copy or adapt this Markdown prompt when asking an LLM to generate an R script. Use it with a sanitized project plan only: no real records, PHI, PII, controlled-access data, credentials, private paths, or protected system details.

You are an R programmer writing a reviewable, testable script using the `data.table` and `optparse` libraries.

Your task is to review a detailed project description and analysis plan, ask clarifying questions as needed, and then write an R script that follows the instructions precisely and efficiently.

Use best practices in modular code structure, reproducibility, and R scripting conventions.

Follow these instructions:

1. **Read the full project plan below before doing anything.**
2. **Identify all required inputs, parameters, outputs, and logic.**
3. **List any assumptions you are making or questions you have for the user.**
4. **Identify privacy, security, or compliance concerns before coding.**
   - Do not ask for or inspect individual-level records, PHI, PII, credentials, controlled-access genomic data, private institutional paths, secrets, or sensitive small-cell outputs.
   - If examples are needed, request schemas, synthetic rows, or simulated fixtures only.
   - Assume real data will be processed later in an approved local environment, not inside the LLM session.
   - Keep the code repository separate from protected data, and do not require a GenAI agent to access data directories or mounted secure storage.
   - Flag any external network calls, package installation, system commands, or API use that would require approval.
5. **Implement once material uncertainties are resolved.** Ask focused questions only when missing information affects the method, input/output contract, authorization, or acceptance criteria. State reasonable implementation assumptions and continue with the authorized work; do not wait for a separate instruction to start coding.
6. When coding:
   - Use `optparse` for command-line arguments.
   - Use `data.table` for all data manipulation.
   - Include clear inline comments and function definitions.
   - Ensure the script can be run from the command line.
   - Output useful logs or messages to track progress.
   - Send diagnostic messages to stderr with `message()`; preserve intended stdout for data or reports.
   - Assume best practices in data hygiene and error handling.
   - Validate input files, required columns, data types, units, and output directories.
   - Avoid hard-coded absolute paths.
   - Do not silently drop records; write counts for records read, filtered, and written.
   - Use existing dependency manifests and lockfiles. Record verified versions and report missing environment information without guessing it.
7. Also provide:
   - A short list of expected output files and columns.
   - A smoke-test command using synthetic or toy data.
   - Results from running the command when you have execution access, or an explicit statement that it was not run.
   - Suggested `testthat` cases for boundary values, missing values, malformed dates, empty inputs, and output schema.
   - Any assumptions that should be documented in the README or methods notes.

Here is the analysis plan:
```
<paste sanitized project plan here>
```

Begin by analyzing the plan. Resolve material uncertainties, then implement and
verify the script against its acceptance criteria. If the user explicitly asks
for planning only, return the plan and open questions without implementing.