Unity Project Setup

Purpose

Lay down the repo and build foundation a team can grow on: correct Unity-aware source control, a predictable folder + assembly layout, reproducible package management, a versioning scheme, a secrets stance, and CI/CD wiring — so the first playable (and everything after) lands in a structure that doesn't fight merges, leak keys, or rot into 20-minute compiles.

Use When

Starting a new Unity repo (or rescuing one set up naively); fixing Git pain (huge repo, scene merge conflicts, broken references after pull); designing assembly architecture; pinning packages for reproducibility; deciding a version/build-number scheme; removing committed secrets; or standing up CI that builds + tests + hands iOS signing to fastlane.

This is the production-engineering / DevOps hygiene discipline. It is distinct from unity-gameplay-systems (which scaffolds the first PLAYABLE) — this skill owns the repo/build foundation that the playable lives inside.

Doctrine (set this up BEFORE the project grows)

1. Configure source control correctly once, on day zero. Unity's binary assets and .meta sidecar files make naive Git painful — a wrong .gitignore or a missing LFS rule is far cheaper to fix before there are 50 commits and 4 GB of textures than after.
2. Always commit .meta files; never commit Library/. A .meta is the asset's identity (GUID + import settings). A missing or orphaned meta silently breaks every reference to that asset. Library/ is a regenerable cache — committing it bloats the repo and conflicts constantly.
3. Reproducible builds beat "works on my machine." Pin package versions, commit packages-lock.json, and keep one headless build entry point so CI and a teammate's clone produce the same artifact.
4. Secrets never touch the repo. Ad unit IDs, analytics keys, signing creds, App Store API keys → environment variables / per-env config / CI secrets, with the secret files .gitignored. This reinforces the repo's own security stance (see unity-ios-secure-backend, unity-monetization).
5. Architecture is enforced by assemblies, not by good intentions. An engine-free Core in its own asmdef gives fast compiles, real unit tests, and dependency boundaries the compiler actually checks.