Setting Up WSL Dev Environment

Bash
# Verify core system deps
for pkg in git curl unzip procps jq; do
  dpkg -s "$pkg" >/dev/null 2>&1 && echo "OK: $pkg" || echo "MISSING: $pkg"
done

Install missing ones with sudo apt-get update && sudo apt-get install -y <pkg>.

Progress:

• Step 1: Confirm working directory lives under /mnt/c/... (never ~ or ext4 /home)
• Step 2: Install/verify base system packages (git, curl, unzip, procps, jq)
• Step 3: Verify Node.js version meets requirement (e.g. >= 22.23.4 or >= 24.22.1); install via nvm/fnm if too old
• Step 4: Verify/install target SDK (e.g. .NET 10) and confirm dotnet --version
• Step 5: Verify gh CLI installed and gh auth status authenticated
• Step 6: Verify git config user.name / user.email set, set them if absent
• Step 7: Configure core.autocrlf=input and .gitattributes (* text=auto eol=lf) on any repo under /mnt/c
• Step 8: Report full version table to the user before proceeding

Step details

Working directory check (always first). Never create files until the exact Windows-backed path is confirmed. If unknown, stop and ask — do not guess or default to ~.

Node version check:

Bash
node --version
# If below requirement:
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
source ~/.bashrc
nvm install --lts

SDK check (example .NET):

Bash
dotnet --version
dotnet --list-sdks

If missing, download install script from the official source, run with --install-dir pointing to a path under the project's Windows-mounted tree if sandboxing is required, otherwise standard location is fine since the SDK itself is tooling, not project content.

GitHub auth check:

Bash
gh --version
gh auth status

If not authenticated, do not attempt to authenticate silently — present the exact command (gh auth login) and wait.

Git identity:

Bash
git config --global user.name
git config --global user.email

If either is empty, ask the user for values rather than inventing placeholders.

CRLF safety for Windows-mounted repos:

Bash
git config core.autocrlf input
cat > .gitattributes <<'EOF'
* text=auto eol=lf
EOF

Bash
npm install --global rea-agents
npx rea-agents setup
npx rea-agents doctor   # or equivalent readiness command — paste full output to user

Do not proceed to any analysis until the doctor/readiness command reports fully green.

Progress:

• Step 1: Confirm Node.js version satisfies REA's requirement (delegate to environment-setup skill if not)
• Step 2: npm install --global rea-agents
• Step 3: npx rea-agents setup — attempt automatic agent registration
• Step 4: If the target agent (e.g. opencode) isn't in REA's supported list, fall back to manual MCP registration
• Step 5: Run readiness/doctor command, capture and report full output verbatim
• Step 6: Only proceed to feature work once readiness is green

Manual MCP registration (when agent unsupported)

1. Read docs/getting-started/installation.md#mcp-registry from the morluto/rea repository for the exact MCP server command/args/env schema.
2. Locate the target agent's config file inside the project directory (never in a global/home dotfile location unless that's the agent's only supported mechanism).
3. Add an MCP server entry following the agent's own schema, e.g. for opencode's config:

JSON
{
  "mcp": {
    "rea": {
      "command": "npx",
      "args": ["rea-agents", "mcp-server"],
      "enabled": true
    }
  }
}

(Verify exact command/args against the installation doc — do not guess the invocation.) 4. Restart/reload the agent session so it picks up the new MCP registration. 5. Confirm the MCP tool surface is visible to the agent (list available tools) before trusting it for analysis.

Bash
find "/mnt/c/Program Files/Unity/Hub/Editor" -maxdepth 1 -mindepth 1 -type d 2>/dev/null
# For a given version:
VER="2022.3.50f1"
ls "/mnt/c/Program Files/Unity/Hub/Editor/$VER/Editor/Data/Managed/"

Progress:

• Step 1: Search standard Unity Hub install locations under /mnt/c/Program Files/Unity/Hub/Editor/*/Editor/Data/Managed/
• Step 2: If found, list installed versions and confirm which one matches the target feature's Unity version
• Step 3: If not found, stop and ask the user: install via Unity Hub (which version?) or supply a path to existing DLLs
• Step 4: Once located, catalog relevant assemblies (UnityEngine.CoreModule.dll, UnityEngine.PhysicsModule.dll, UnityEditor.*.dll, etc.) relevant to the current feature
• Step 5: Copy or reference these DLLs from a path under the project's /mnt/c working tree (an ignored, non-committed subfolder) rather than analyzing them in place, to keep REA inputs reproducible

Common managed assembly locations by concern

Given a feature name (e.g. "Rigidbody.AddForce"), investigate in this order:

1. Locate the declaring type and assembly via REA's inventory/metadata tools.
2. Pull the full member signature (overloads, default parameter values, access modifiers).
3. Decompile/inspect IL for the method body to understand actual logic, not just the public contract.
4. Trace references: what does this method call internally, what calls it, what fields/state does it touch.
5. Check related types (enums, structs, attributes) that shape behavior (e.g. ForceMode, RigidbodyConstraints).

Progress:

• Step 1: Identify target assembly and fully-qualified type/member name
• Step 2: Extract signature(s): parameters, defaults, overloads, return type, visibility, attributes
• Step 3: Inspect IL body for the member(s) to understand real