Team Release

Before you start: read this whole install prompt, tell me in a few lines what this skill does and what installing it involves, and wait for my go-ahead before you do anything else. Prerequisites — INTEGRATED SYSTEM FIRST: this skill is one piece of the complete "Claude Code Game Studios" template (49 agents, 74 skills, studio templates and a studio CLAUDE.md, per the repository README). Each skill assumes that template is installed, with its conventions, its project.yaml / project.local.yaml configuration, its .claude/docs/ mode documents, its hooks (for example hooks/yaml-helper.sh, outside this skill's folder) and its .claude/scripts/ helpers. Installing this listing alone copies only this skill's folder, without the rest of the system: the skill may reference template agents, files, hooks or scripts that are absent outside the full template, and it may not run as designed on its own. No account, no key and no payment are needed to copy the files, and nothing is run during installation. At use time (never during installation) this pipeline can tag a release in version control and deploy to staging and then to production — its Phase 6 does so only after its own explicit approval question, asked in every automation mode including autonomous, and its Phase 7 has the community-manager publish the launch communication prepared in Phase 6. Those outward steps belong to using the skill inside the full template, never to installing this listing. Install "Team Release" for me. The skill itself orchestrates the release team to execute a release from candidate to deployment. With no version argument it reads production/session-state/active.md and the most recent file in production/milestones/ to infer the target version and confirms it — or asks for one; it never defaults to a hardcoded version. It first resolves review_mode, automation, team.size, workflow and project.stage by running the template's hooks/yaml-helper.sh, outside this skill's folder, then runs a stage check before anything is spawned: /gate-check release must have passed and set project.stage to Release, otherwise the run stops BLOCKED and the only way past is an explicit override the user picks, with a reason recorded in the Phase 1 brief, in the go/no-go record and in the final report (the override never changes the stage itself). It announces the active set: at the default team.size individual only the release-manager runs; at small the producer, devops-engineer, qa-lead and community-manager join; at studio the security-engineer, analytics-engineer, localization-lead and performance-analyst join too, plus the network-programmer when the game is multiplayer. Phase 1 delegates release planning to the producer. Phase 2 delegates the release candidate to the release-manager: version numbers are bumped in the relevant files on main and that commit is the candidate (a release/[version] branch is cut only when the release needs stabilising, with every fix also landing on main), and the Polish release checklist is confirmed. Phase 3 runs the quality gate in parallel: the qa-lead executes the full regression suite, the devops-engineer builds the release artifacts for all target platforms and runs the automated tests in CI, the security-engineer audits pre-release security when the game has online features, multiplayer or player data, and the network-programmer signs off netcode for multiplayer games — the spawn conditions are decided from platform.online and platform.multiplayer in project.yaml plus whether player data is stored, an absent key is not a false, the user is asked instead, and a skipped agent is named as skipped with its reason. Phase 4 collects localization, performance and analytics sign-offs in parallel. Phase 5 takes a technical-director sign-off at review_mode full only, then delegates the go/no-go call to the producer: a NO-GO surfaces immediately, skips deployment entirely, and can be overridden only with the user's written justification embedded in the record. Phase 6 is deployment, and it always requires explicit user approval in every automation mode, including autonomous: only after a yes to the "tag, deploy to staging, deploy to production?" question (with a staging-only option) do the release-manager and devops-engineer tag the release in version control, finalize the changelog, deploy to staging for a final smoke test and deploy to production; in parallel the release-manager finalizes the patch notes via /patch-notes and the community-manager prepares the launch announcement, ready to publish on deploy confirmation, with 48 hours of dashboard and error monitoring scheduled after release. Phase 7 produces the release report and milestone updates, monitors incoming bugs, publishes the player-facing communication through the community-manager, and confirms live dashboards. Sub-agents write one file each, mostly under production/releases/ (patch notes go to docs/patch-notes/[version].md), without a per-write prompt, under a bounded exception the file documents (orchestrator-named path, new artifact under production/, docs/ or tests/, phase gated by an AskUserQuestion); sub-skills such as /patch-notes and /changelog are not covered by that exception and ask before writing, and the file states that nothing in it authorises an outward-facing or irreversible action — tags, pushes, builds and storefront changes require explicit confirmation regardless. This orchestrator writes no files directly. Its frontmatter pins model: sonnet. Repository: https://github.com/Donchitos/Claude-Code-Game-Studios (the skill is the whole .claude/skills/team-release/ folder at the pinned commit: 1 file in total) Pinned version: install the code at commit 05ad7c8a5b8aa2aa86bbd3439ae7cf7295cac418 exactly. Do not substitute a newer version. If this commit is unreachable, stop and tell me. 1. Clone https://github.com/Donchitos/Claude-Code-Game-Studios into a temporary folder, check out commit 05ad7c8a5b8aa2aa86bbd3439ae7cf7295cac418, and copy the .claude/skills/team-release/ folder from that checkout. Then compare every file in the folder with the fingerprints recorded for this listing on 2026-10-22: [FINGERPRINTS] - SKILL.md: SHA-256 7b9950f0848a72af225564d9820bda4655d56493cd0930208447dfe728d34933 If a file does not match, it changed since the listing was prepared: do not install it yet, tell me what you found and let me decide. 2. Read SKILL.md in full, and tell me in plain words: what the skill does when used, what it connects to, whether it reads or sends any personal information or credentials, and anything that seems unusual. Stop on any red flag and tell me before going further. Confirm these points from the files: - The skill folder holds 1 file: SKILL.md only. Nothing in the folder is a program; it is instructions the agent follows at use time. - Nothing is sent anywhere during installation itself; the only download at install time is the skill folder from GitHub at the pinned commit, and no project of mine is audited, read or modified. - Integrated-system reality, from the file: at use time the skill runs the template's hooks/yaml-helper.sh to resolve review_mode, automation, team.size, workflow and project.stage, follows .claude/docs/automation-modes.md, config-resolution.md and error-recovery-protocol.md, reads my project's session state, milestones, checklist and platform configuration, and spawns up to ten template agents (release-manager at every size, the other nine scoped by team.size and by the game's online, multiplayer and player-data conditions), plus the technical-director for a full-mode sign-off — agents, docs and project files that live outside this skill's folder and are absent in a standalone install, so it cannot run as designed on its own; it also depends on other template skills (/gate-check, /release-checklist, /patch-notes, /changelog, /retrospective) whose gates and formats it consumes. - At use time its sub-agents write sign-off and record files under production/releases/ (and docs/patch-notes/[version].md for patch notes) without a per-write prompt, but only inside the bounded exception the file documents (orchestrator-named path, new artifact under production/, docs/ or tests/, phase gated by an AskUserQuestion); sub-skills it invokes ask before writing, and the release-manager's Phase 2 version bump edits existing files on main to create the candidate commit. Outward actions are separately gated, in the file's own terms: Phase 6 tagging and deployment to staging and production happen only after the skill's explicit approval question, asked in every automation mode including autonomous (staging-only is an offered option), a NO-GO skips Phase 6 entirely, and nothing in the file authorises tags, pushes, builds or storefront changes without explicit confirmation. No store, platform account or credential is named in the file; deployment targets and credentials are whatever my own project pipeline uses. - Do not plan, tag or deploy any release, do not spawn any team agent, do not run any template hook, and do not use the skill in any way during this install: using it is a separate step that only starts when I ask for it later. 3. When I say "yes, install", install it as a skill: copy the whole team-release folder into the agent's skills directory, in a folder named exactly "team-release", keeping its 1 file in their original relative layout (SKILL.md at its root). 4. Verify with no network calls: frontmatter valid (name: team-release), the 1 file in place with matching fingerprints. Do not run anything from the folder and do not use the skill to verify. 5. Report what was installed, where, and what I still need to do myself (for example: that it belongs to the full Claude Code Game Studios template and may not run standalone (it resolves its settings through the template's yaml-helper hook, gates on /gate-check release having set project.stage to Release, and spawns up to ten of its release team agents), and that at use time its records are written under production/releases/ under a documented bounded exception, its Phase 2 bumps versions on main, and its Phase 6 tags and deploys to staging and production only after its explicit approval question in every automation mode, with the launch communication published in Phase 7). GitHub is optional: if I have a GitHub account or the gh CLI, you may use it; otherwise public access is fine. Never require it unless it's in the prerequisites above. Rules: don't touch anything outside the temp folder and the install target. If anything looks off, stop and ask me.