Initialize Game Binaries

Use the repository-root script as the only entry point for downloading, merging, depot fallback, and BinSync recovery setup. Never overwrite an existing binary, substitute an unlisted version, or continue after a failed step. This skill handles only disposable binary/IDA state: never restore snapshot YAML into bin/ or hydrate tracked bin_artifacts. Source-owned symbol truth is already versioned under bin_artifacts/<GAMEVER>/.

Select GAMEVER

1. Extract an exact GAMEVER from the user's request. Resolve latest only when the user explicitly requests latest.

2. If the user did not specify a version, run:

   uv run init_gamebin.py versions
   

   Tell the user which entry is latest and ask: Which GAMEVER do you want to initialize? Wait for an explicit version before continuing.

3. Reject values absent from download.yaml; do not guess or silently use latest.

Decide BinSync

BinSync recovery is opt-in. Decide whether to enable it before preparing binaries:

1. Probe availability from the owning repository root:

   uv run init_gamebin.py check-binsync
   

2. If the probe exits 1 (unavailable), tell the user BinSync initialization is skipped and why (BinSync unavailable: <reason>), then proceed to preparation without enabling BinSync.

3. If the probe exits 0 (available), ask the user whether to enable BinSync and wait for an explicit yes/no. Never enable BinSync without explicit consent, and never skip the probe.

   • Yes → prepare with --binsync enable.
   • No → prepare with --binsync skip (or omit the flag).

Prepare Binaries

Run from the owning repository root with the BinSync decision applied:

uv run init_gamebin.py prepare <GAMEVER-or-latest> --binsync <enable|skip>

Never pass --create-missing-binsync-remotes from this manual skill flow. That mutating option is reserved for the trusted build-on-self-runner workflow.

Without --binsync, BinSync is skipped and never probed. --binsync enable probes first and fails (instead of skipping) when the environment cannot run BinSync. The script checks existing binaries, downloads and non-overwritingly merges gamebin-<GAMEVER>.7z when needed, and uses the Steam depot fallback only for a missing Release asset. After every configured Windows and Linux binary exists, it:

1. Resolves targets in first-seen config order, Windows before Linux, and deduplicates repeated real binary paths.
2. Preflights every target before making BinSync changes: strict existing sidecars, matching local .bsproj repositories, and GitHub remote/default-branch/binary_hash state.
3. Uses gh to read public repositories without requiring HLND2T organization permissions. Only an explicit HTTP 404 is treated as missing; every other API failure stops the command.
4. Requires the HLND2T/CS2_VibeSignatures_binsync_<GAMEVER>_<MODULE_FILENAME> repository to already exist during this manual skill flow; a missing remote stops the command with a clear reason. Only the trusted build workflow passes the explicit repository-creation option.
5. Restores a previously empty remote from every local binsync/* branch when a valid unlocked <MODULE_FILENAME>.bsproj exists. Otherwise it creates the standard BinSync Root commit, binsync/__root__, and binsync/<OS_USER> branches. It sets the default branch only for a previously empty repository.
6. Writes <MODULE_FILENAME>.binsync.json only after the remote validates successfully. The sidecar uses the current OS user as a fallback, the canonical HTTPS remote, explicit <MODULE_FILENAME>.bsproj, the binary MD5, force_user: false, auto_clone: true, and auto_sync_all: true.

The script never reads or writes BinSyncDLConfig.toml, never clones missing .bsproj repositories into bin/, and never fetches or pushes an already-valid remote/local pair. IDA's BinSync auto-recovery performs the later clone.

Existing sidecars must contain the six required fields and match semantically. They may also include auto_sync_all, which must be true when present; unknown extra fields remain a conflict. Existing local repositories must have the expected origin, binsync/__root__, and binary_hash. Existing non-empty remotes must already use binsync/__root__ as their default branch and expose the matching binary_hash. Stop on any conflict; never overwrite, move, delete, repair, or change the default branch of existing state. A local binsync.lock is allowed for read-only validation, but it blocks restoring a missing or empty remote from that local repository.

If the command fails, stop immediately and report its exact error as:

<skill_error>ERROR REASON</skill_error>

Do not attempt an alternate download, edit .env, or proceed to analysis.

Warm Up IDB (optional)

After binary preparation succeeds, ask whether to warm the IDA databases for the selected GAMEVER. Warmup runs full IDA auto-analysis on every configured binary (via warmup_idb.py) and leaves <binary>.i64 beside each binary so later analysis is fast. It is slow and resource-heavy, so it is opt-in.

1. Resolve a Python interpreter with idalib — the same probe the workflows use:

   $pythonExe = (Get-Command python -ErrorAction SilentlyContinue).Source
   & $pythonExe warmup_idb_worker.py --print-ida-version
   

   If the probe fails or prints no version, tell the user IDB warmup is skipped and why (no Python with idalib available), then finish without warming.

2. If the interpreter is available, ask the user whether to warm the IDB databases for <GAMEVER> and wait for an explicit yes/no. Never warm without explicit consent.

   • Yes → run the warmup producer from the owning repository root:

     uv run python warmup_idb.py <GAMEVER> --python "$pythonExe"
     

     Already-warm databases (an existing .i64/.idb with no .id0 lock) are skipped; add --force only if the user wants every configured database invalidated and re-warmed. If the command fails, stop and report its exact error to user.

     Do not silently continue after a failed warmup.

   • No → skip warmup and finish.

Report the selected GAMEVER, binary preparation result, BinSync summary, and optional warmup result. State that symbol truth remains under tracked bin_artifacts/; do not offer snapshot restoration or IDB renaming.