Setup Environment

---
name: setup-environment
description: "Sets up language toolchains, project folders, data classification levels and studio configuration for the chosen model stack."
argument-hint: "[matlab-dynare|python|julia|r|gams|stata|eviews|gempack|mixed]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, AskUserQuestion, Task
---

# /setup-environment — Setup Environment

**Category:** Onboarding · **Primary agent:** `python-julia-engineer`

Sets up language toolchains, project folders, data classification levels and studio configuration for the chosen model stack.

Arguments: `$ARGUMENTS`

## Purpose
Set up the technical foundation for modeling work: approved language toolchains, folder structure with data classification levels, reproducible environment files, and studio configuration, verified by a smoke test in each chosen language. Confidential-data handling is configured before any data enter the project.

**Use it when** starting a new project or onboarding a team to the studio.

**Do not use it when** only configuration values change (`/settings`).

## Before you start
1. **Check required inputs.** For each input below record `FOUND` or `ABSENT` (never 'assumed'):
   - studio-config.yaml
   - installed toolchains
   If a required input is `ABSENT`, that part is **`NOT ASSESSED — NO DATA`**: do not estimate or invent it; name what is missing and which skill produces it. If all required inputs are absent, stop and say so.
2. **Check confidentiality.** Identify the data classification level of the inputs (`.claude/docs/confidentiality-and-ai-use.md`). Do not proceed with restricted or confidential data in a way the policy does not allow.
3. **Collaboration.** Follow `.claude/docs/collaboration-protocol.md`: ask questions first, present options, get approval before writing files, and update `production/session-state/active.md` after each approved section.

## Agents
- `python-julia-engineer` — primary agent; coordinates the work and integrates results
- `matlab-dynare-engineer` — Engineers MATLAB, Dynare, IRIS, RISE and Octave codebases; legacy model maintenance and migration
- `reproducibility-engineer` — Guarantees reproducibility
- `data-governance-metadata-specialist` — Owns data governance and metadata

Run these agents as subagents (the `Task` tool), in parallel where the steps are independent. Subagents only write to the paths named in your instructions.

## Key design decisions (present options, let the user choose)
| Decision | Typical options | What it changes |
|---|---|---|
| Languages | Python, Julia, R, MATLAB/Dynare, GAMS, Stata, EViews, GEMPACK | Toolchains and skills used |
| Environments | lock files, containers | Reproducibility |
| Data classes | public, internal, restricted, confidential | Handling rules |

## Workflow
1. Ask which stack(s) the team uses and which are approved by your IT policy
2. Create or verify the folder skeleton and data classification levels (`data/raw`, `data/processed`, `data/restricted`)
3. Propose environment files (lock files, containers) and ask before creating them
4. Record decisions in `studio-config.yaml` and a stack ADR
5. Verify by running a minimal smoke test in each chosen language
   - For R, check that `Rscript` is on the PATH, record the R version, and initialise `renv` so `renv.lock` pins the packages
   - For EViews (Windows only), find the executable (for example `EViews13.exe`) and run a one-line program in batch (`/run` with `exit`), or check that `pyeviews` can start it; if it cannot be started from the terminal, record that runs are done by the user and the agents write the programs only
   - For GEMPACK, check the license level (source-code or executable-image), that `tablo` or `gemsim` and `sltoht` are on the PATH, and run a zero-shock test of a small model; if RunGTAP is the only interface, record that runs are done by the user and the agents write the `.tab` and `.cmf` files only
   - For Stata, find the executable (`stata-mp`, `stata-se` or `stata`, or `StataMP-64.exe` on Windows) and run a one-line do-file in batch mode (`-b do`); if it is not callable from the terminal, record that runs are done by the user and the agents write the do-files only
   - Include `python tools/lego.py` on a sample manifest to confirm the lego engine runs

## Checkpoints with the user
- Before creating environment files
- Before recording the stack decision

## Common pitfalls
- Tools not approved by institutional IT
- Unpinned environments
- Stata user-written packages not recorded
- R packages installed without `renv`, so versions drift
- EViews workfiles edited by hand and treated as the source
- Licensed databases (for example GTAP) committed to git or shared
- Data added before classification is configured

## Output
`studio-config.yaml and docs/architecture/adr-stack.md`

The configuration file records the stack and defaults; the ADR records the decision and its reasons.

## Gate / verdict
- Smoke test runs from a clean shell
- Confidential-data handling is configured before any data is added
- Environment files pin versions

## Suggested next steps
- `/data-requirements`
- `/model-brief`