How to use the Team Release Orchestrator agent skill

What is an agent skill, and what does team-release make the agent do?

An agent skill is a folder containing a SKILL.md file that gives Claude Code extra instructions for a specific job. When the skill is invoked, the agent follows those instructions instead of improvising the whole process.

The team-release skill, from the Donchitos/Claude-Code-Game-Studios project under the MIT licence, makes the agent orchestrate a release team: release-manager, qa-lead, devops-engineer and producer. It works out the target version, checks that the project's release readiness gate has passed, then moves through phases in which it plays or delegates to those roles. It asks you to confirm decisions at phase transitions and can write release artifacts such as go/no-go records and changelogs.

• Infers the target version from the argument or from project milestone files
• Stops if the project stage shows the release gate has not passed
• Asks for confirmation at each phase transition
• Can write go/no-go records (go-no-go-[version].md) and changelogs

Install the team-release skill from the ZIP

Download the ZIP for the skill from this page and unzip it. The skill is a single file, SKILL.md. Put the team-release folder in one of two places, depending on how you want it available.

For a single user across all projects, place it in ~/.claude/skills/. For one project only, place it in that project's .claude/skills/ folder. Claude Code can then find the skill when you start a session in the right location.

If you use the Claude apps instead of Claude Code, you can upload the skill under Settings → Capabilities → Skills.

• Personal install: ~/.claude/skills/team-release/
• Project install: <your-project>/.claude/skills/team-release/
• Claude apps: Settings → Capabilities → Skills, then upload

Check the requirements before you run it

The skill depends on the surrounding studio folder structure. It references hooks, docs and config files that come with the Claude Code Game Studios template, and it reads a config resolver script, yaml-helper.sh, that needs a bash shell.

For version inference it looks for production/session-state/active.md and production/milestones/. Those folders are optional, but without them you will be asked for the version number directly.

• Claude Code with the studio's .claude folder (hooks, docs and config files the skill references)
• A bash shell to run the yaml-helper.sh config resolver
• Optional: production/session-state and production/milestones folders for version inference
• Project stage must be Release, which only a passing /gate-check release sets

Trigger the skill with a natural request

Ask for the release in plain language, or call the skill directly with an optional version argument. The argument-hint in the skill is a version number or 'next', plus an optional --review flag set to full, lean or solo.

If you give no version, the skill reads your milestone data and proposes one, then asks you to confirm. If it cannot find a version, it asks you for one, for example v1.0.0, and does not assume a default.

• "Run the team release process for our next release."
• "Orchestrate the release for v1.2.0."
• "Start the release team pipeline with a lean review."

Understand the stage check and the decision points

Before any agent is spawned, the skill checks project.stage. Only a passing /gate-check release sets it to Release. If the stage is anything else, the skill stops and asks whether to run /gate-check release first. You can choose to override, but the override is recorded in the go/no-go record and the final report.

At each phase transition the skill presents the subagent proposals as selectable options. How much it runs on its own depends on the automation mode: in collaborative mode you approve every phase, in guided mode it advances unless a phase is blocked, and in autonomous mode it runs end to end, logging each outcome. Decisions in always-ask categories always prompt you.

• Collaborative: you approve each phase before the next starts
• Guided: advances automatically unless a phase is BLOCKED
• Autonomous: runs end to end and records outcomes with log_decision
• The Phase 6 deploy step is gated by a question to you

Safety notes: scripts and network access

The skill runs scripts: it executes the yaml-helper.sh config resolver through bash. It does not use the network, according to the skill's assessment. It can read and write files in your project, including release artifacts.

Do not expect unattended deployment. The skill asks for confirmation at decision points, and the deploy step waits for your answer. Review any file it writes, such as a changelog or go/no-go record, before you rely on it.

The skill's full phase details are not fully visible in the source file on this page, because the text ends mid-list. Read the complete SKILL.md yourself before running it on a real release.

• Runs scripts: yes (bash yaml-helper.sh resolve_config)
• Uses network: no
• Writes files such as go-no-go-[version].md and changelogs
• Deploy is gated by your confirmation

Tips for getting useful results

Run /gate-check release before team-release so the stage is set and the readiness record exists. Keep milestone files in production/milestones/ so the version can be inferred accurately.

Pick the review depth that fits the release. Use lean or solo for small releases where you want fewer checks, and full when you want the complete record.

• Run /gate-check release first
• Keep production/milestones/ current so version inference works
• Give an explicit version number when you are unsure of the inference
• Read every AskUserQuestion prompt before answering