/steam-publish

name: steam-publish
description: >
  Publishes or updates a game on Steam with Steamworks and SteamPipe: depots, app_build .vdf
  scripts, steamcmd uploads, beta branches, SetLive, store review and Coming Soon. Use for
  steamcmd, ContentBuilder, "Failed to get application info", Steam Deck Verified or "ship it on
  Steam". Not for itch.io (`itch-publish`) or Steamworks SDK calls in game code.

Steam Publish (Steamworks + SteamPipe)

Take a finished build to a live Steam store page. Two tracks run in parallel and both must be approved before release: the **store page** (presence) and the **build** (SteamPipe upload plus the Game Build checklist). The agent writes and checks the build scripts and drives steamcmd; the partner-site steps are the user's, so ask for them and for the IDs they produce. Deep build-script, CI and troubleshooting detail lives in `references/steampipe-build-scripts.md`. Fees, waiting periods and review times are in Version notes at the end.

When to use

• Setting up a Steam app, configuring depots and packages, writing `app_build_*.vdf` /

`depot_build_*.vdf`, uploading with steamcmd, managing beta branches, getting through store and build review, and releasing or updating a Steam title.

• Project signals: `steam_appid.txt`, a Steamworks SDK `tools/ContentBuilder/` folder,

`*.vdf` build scripts, steamcmd in CI.

**Not for:** itch.io (use `itch-publish`); pricing strategy, tax or legal advice (point the user at the Steamworks docs and their own advisers).

**Steamworks SDK integration is out of scope.** For `SteamAPI_Init`, achievements, stats, Steam Input, overlay, Cloud, lobbies or networking in game code, read Valve's [Steamworks API overview](https://partner.steamgames.com/doc/sdk/api) and use the engine's binding: [GodotSteam](https://godotsteam.com/) for Godot, [Steamworks.NET](https://steamworks.github.io/) or Facepunch.Steamworks for Unity and C#, or Unreal's Online Subsystem Steam plugin. This skill only uses the SDK's `tools/ContentBuilder`.

One-time setup (the user does these)

1. **Partner account and Steam Direct fee.** Ask the user to finish onboarding (legal identity, bank, tax) and pay the per-app fee, then report the **App ID**. Tax verification and, for a first few titles, a waiting period between paying and releasing both run in calendar time, so the fee should be paid well before the launch date (numbers in Version notes). 2. **A dedicated build account.** Ask the user to create a separate Steam account in the partner group with only **Edit App Metadata** and **Publish App Changes To Steam**. Posting Coming Soon and releasing also need **Manage pricing and discounts**, which the build account can do without. After release, setting a build live on `default` sends a confirmation to the account's Steam Mobile Authenticator or phone, so the account that does it needs one. 3. **Steamworks SDK** on the upload machine. Only `tools/ContentBuilder/` is used: `builder*/` holds steamcmd per OS, `content/` the files players get, `scripts/` the `.vdf` files, `output/` logs and the chunk cache.

Never commit the account password or steamcmd's `config.vdf` login token. The reference has the supported CI token workflow.

Workflow

1. **Configure the app in App Admin.** Ask the user to do this and report the depot IDs:

• *Installation*: one launch option per OS. A sub-folder exe goes in the Executable field

with no leading slash or dot. On macOS point at `Game.app`, not the binary inside it (see Gotchas).

• *Depots*: one depot per bucket of files ("Base Content", "Windows Content"). Leave *[All

languages]* / *[All OSes]* unless the depot really is OS- or language-specific.

• *Associated Packages & DLC*: add every depot to the **Developer Comp** package and to the

store package, or nobody (including the developer) owns the content.

• **Publish** the configuration. Unpublished config is the most common upload failure.

2. **Store page track.** Ask the user to fill assets, description, tags, trailer and system requirements, then complete the **Content Survey** (general content, mature content, generative AI) before submitting. Then **Mark as ready for review**. Approval does not publish the page: someone must click **Post as Coming Soon**, and the minimum Coming Soon period only runs while the page is public. 3. **Write the build scripts.** One depot: the minimal `app_build` below. Several depots or platforms: one `depot_build_<DepotID>.vdf` per depot (reference, section 1). 4. **Check the scripts** with `scripts/check_steam_build.py` and fix every ERROR. Then do a first run with `"Preview" "1"`, which writes logs and a manifest and uploads nothing. 5. **Upload.** Remove `Preview`, run steamcmd with the build account (Pattern 3). It chunks files at about 1 MB, uploads only new chunks and registers a global **BuildID**. 6. **Set the build live on a beta branch first.** Either `"SetLive" "<beta>"` in the script or, on `https://partner.steamgames.com/apps/builds/<AppID>`, **Preview Change** then **Set Build Live Now**. Ask the user to install that branch and report that it launches on every OS the store page lists. Then promote it to `default` by hand: `default` cannot be set from a script. 7. **Build review.** Store presence must be submitted first. Valve reviews the build that is live on `default`: near-final, launching on every listed OS, with every feature the store page claims. Ask the user to complete the Game Build checklist and **Mark as ready for review**. Review happens once; later updates are not re-reviewed. 8. **Release.** Titles never release themselves. When both tracks are approved and Coming Soon has run its time, the user clicks **Release App**, **Publish Now**, then **Release Now**. 9. **Updates later:** upload, set live on a beta, test, promote to `default`.

Patterns

1. Minimal app build script: `app_build_1000.vdf`