Game CI/CD Pipeline

Use this skill when the job is choosing the next game-pipeline artifact, not dumping a generic DevOps essay.

game-ci-cd-pipeline

should answer two linked questions per run:

Which signal tier / promotion lane is this?
- ```
branch-gate
```
  — fast merge/commit validation
- ```
nightly-package-candidate
```
  — slower scheduled or manually triggered QA/review candidate builds
- ```
release-certification-candidate
```
  — protected, signed, approval-heavy release or cert candidates
Which packet is the smallest honest next artifact inside that tier?
- pipeline setup
- stage split
- cache policy
- preflight readiness
- artifact/release hygiene
- CI-signal hardening
- or route-to-log-triage

Read these before choosing the packet:

references/intake-packets-and-route-outs.md
references/pipeline-patterns.md
references/signal-tiers-and-promotion-lanes.md

When to use this skill

A Unity or Unreal team needs to set up CI/CD from scratch without overengineering it.
A pipeline is repeatedly flaky, slow, or opaque, and the real problem is workflow structure rather than one isolated log.
Build, cook/package, cache, artifact, or release-hand-off steps keep breaking trust in the pipeline.
A team still ships demo/review/release builds manually and needs the first reproducible pipeline packet.
A publisher helper, contractor, or technical lead needs a compact game-pipeline audit brief.

When not to use this skill

The main job is identifying the first actionable failure inside one specific Unity/Unreal build log →
```
game-build-log-triage
```
.
The main job is milestone coordination across design, QA, build pressure, and launch timing →
```
bmad-gds
```
.
The main job is runtime profiling or frame-time bottleneck diagnosis →
```
game-performance-profiler
```
.
The main job is Steam page / wishlist / launch-store operations →
```
steam-store-launch-ops
```
.
The main job is generic non-game CI/CD for ordinary web/backend repos → use the repo's broader DevOps skills instead.

Instructions

Step 1: Classify the signal tier first, then choose one primary packet type

Normalize the request into exactly one signal tier and one primary packet.

yaml

game_pipeline_packet:
  signal_tier: branch-gate | nightly-package-candidate | release-certification-candidate | unknown
  packet_type: pipeline-setup | stage-split | cache-policy | preflight-readiness | artifact-release | ci-signal-hardening | route-to-log-triage
  engine: Unity | Unreal | mixed | unknown
  ci_surface: GitHub Actions | Unity Build Automation | Jenkins | TeamCity | other | unknown
  target_platforms: Windows | macOS | Linux | Android | iOS | console | mixed | unknown
  release_context: prototype | internal QA | demo | playtest | certification | launch | live patch | unknown
  evidence_level: strong | partial | thin

Signal-tier meanings:

```
branch-gate
```
— fast merge/commit validation where expensive packaging should stay exceptional
```
nightly-package-candidate
```
— scheduled or manually triggered QA/review/demo candidate builds that are heavier than ordinary branch CI
```
release-certification-candidate
```
— protected, approval-heavy, signed, store-bound, or cert-bound candidate work

Packet meanings:

```
pipeline-setup
```
— first reproducible pipeline plan for a team still doing too much by hand
```
stage-split
```
— separate restore/build/test/cook/package/publish so the first failing stage is visible
```
cache-policy
```
— stop superstition around
```
Library
```
,
```
Intermediate
```
,
```
Saved
```
, DDC, or package caches
```
preflight-readiness
```
— surface SDK/signing/toolchain/platform prerequisites before expensive packaging
```
artifact-release
```
— fix artifact naming, retention, candidate-vs-release clarity, and QA handoff
```
ci-signal-hardening
```
— improve feedback speed and trust without rewriting everything
```
route-to-log-triage
```
— the request is mostly one red build/log and should move to
```
game-build-log-triage
```

Step 2: Gather the minimum credible evidence

Pull only the smallest packet needed to justify the decision:

engine and version if known
current CI surface or workflow file
current trigger shape: PR/push, schedule/manual, protected release lane, or unknown
target platforms and release context
repeated failure pattern: compile, package, toolchain, cache, artifact confusion, speed, or trust
what still happens manually after CI finishes
current artifact naming / retention or approval rules if candidate promotion is part of the pain
one recent failing job/log if the team keeps pointing at a single red build

If evidence is thin, keep confidence low and prefer

route-to-log-triage

or a narrow packet over a fake full redesign.

Step 3: Choose the signal tier explicitly

Decide which lane owns the pain before suggesting the packet:

branch-gate
when the complaint is slow PR/merge validation, heavy packaging on every branch, or weak fast feedback
nightly-package-candidate
when QA/review/demo builds need heavier packaging, broader target coverage, or scheduled/manual promotion outside normal branch CI
release-certification-candidate
when the work is approval-heavy, signed, store/cert-bound, or should have stricter artifact retention than ordinary CI
unknown
only when the available evidence cannot distinguish the lane yet

If the user mixes multiple lanes, pick the lane that is currently bottlenecking trust and name the others as follow-up route-outs.

Step 4: Classify the primary blocker

Choose one primary blocker and at most one secondary blocker.

Primary blockers

```
reproducibility-drift
```
```
stage-boundary-blur
```
```
dependency-cache-policy
```
```
artifact-release-hygiene
```
```
platform-toolchain-readiness
```
```
feedback-speed-confidence
```
```
single-log-not-pipeline
```
```
unknown-needs-more-evidence
```

Typical mappings:

"Works on one machine but not in CI" →
```
reproducibility-drift
```
"Our workflow is one giant job and we cannot tell what failed" →
```
stage-boundary-blur
```
"We keep deleting caches until it passes" →
```
dependency-cache-policy
```
"QA never knows which build is correct" →
```
artifact-release-hygiene
```
"Android/iOS/console packaging fails late" →
```
platform-toolchain-readiness
```
"Builds are slow and nobody trusts the signal" →
```
feedback-speed-confidence
```
"Here is one failing packaging log" →
```
single-log-not-pipeline
```

Step 5: Run the boundary check

Before writing advice, verify the lane:

Is this a structural pipeline question or just a failing log?
Does the chosen signal tier match the actual trigger/approval/artifact problem?
Is the best next artifact one of the packet types above?
Are you staying inside game-engine pipeline work instead of drifting into generic web-app DevOps?
Are engine-specific details helping the diagnosis rather than bloating the front door?

If the answer is mostly "this is one failing log", route to

game-build-log-triage

and leave a short handoff packet. If the answer is mostly "this is really release-gate policy", route the policy decision to

testing-strategies

and keep this skill on game-engine implementation shape.

Step 6: Build the packet brief

Return this exact structure:

markdown

# Game CI/CD Brief

## Packet choice
- Signal tier: branch-gate | nightly-package-candidate | release-certification-candidate | unknown
- Packet type: ...
- Engine: ...
- CI surface: ...
- Release context: ...
- Confidence: high | medium | low

## Evidence used
- Workflow / system context: ...
- Repeated failure pattern: ...
- Manual steps still outside CI: ...
- Gaps / assumptions: ...

## Primary blocker
- Bucket: ...
- Why it matters now: ...
- Evidence: ...

## Secondary blocker
- Bucket: ...
- Why it matters now: ...

## Recommended pipeline shape
1. ...
2. ...
3. ...

## Engine and platform checks
- Unity / Unreal specifics: ...
- SDK / signing / toolchain: ...
- Cache or artifact policy: ...

## Recommended next artifact
- Choose one: pipeline setup plan | workflow stage split brief | cache-key policy | platform preflight checklist | artifact/release checklist | CI-signal hardening plan | log-triage handoff packet

## Route-outs
- Skill: ...
- Why: ...
- Packet to pass: ...

## What not to do yet
- 1-3 bullets that avoid brittle rewrites or cargo-cult caching

Step 7: Tailor the packet to the engine and signal tier

For Unity

watch engine/editor version pinning
ask whether
```
Packages/manifest.json
```
/ lock inputs and platform modules are stable
separate package restore, build, test, and package stages
treat
```
Library/
```
and package caches as explicit policy, not ritual cleanup
for
```
branch-gate
```
, bias toward fast compile/test/smoke feedback and cancel-in-progress behavior
for
```
nightly-package-candidate
```
or
```
release-certification-candidate
```
, make candidate naming, build-target grouping, signing, and artifact retention explicit

For Unreal

keep UBT/UHT, cook, package, and publish mentally separate
call out plugin/module drift, asset redirect fallout, and AutomationTool visibility
distinguish DDC/cache questions from packaging/log-root-cause work
make platform packaging prerequisites visible before late-stage failure
for
```
branch-gate
```
, avoid hiding every merge behind full cook/package unless the project risk truly requires it
for
```
nightly-package-candidate
```
or
```
release-certification-candidate
```
, make cook/package duration, target-specific prerequisites, and publish/promotion rules explicit

Step 8: Ask for the smallest missing packet

If confidence is low, request only what changes the decision:

current workflow file or job outline
trigger shape (PR/push vs schedule/manual vs protected release lane)
engine version and target platforms
one recent failed job/log if the issue may be
```
single-log-not-pipeline
```
current artifact naming / retention / approval pattern
what still happens manually after CI completes

Output format

Always return a short game pipeline brief.

Required qualities:

choose one signal tier and one primary packet type
separate structural pipeline work from one-off log triage
recommend one next artifact, not a full platform rewrite
stay around 300-550 words unless the user asks for more
keep release/demo context visible when it changes the priority
make candidate promotion / approval truth explicit when it changes the answer

Examples

Example 1: Unity cache superstition

Input

Our Unity GitHub Actions build passes locally but fails after package updates. We keep deleting caches and rerunning until it works.

Good output direction

packet type:
```
cache-policy
```
primary blocker:
```
dependency-cache-policy
```
secondary blocker:
```
reproducibility-drift
```
next artifact:
```
cache-key policy
```
route-out remains optional unless one specific log becomes the real question

Example 2: Heavy packaging on every branch

Input

Our PR pipeline takes 70 minutes because Android packaging runs on every branch. What should change first?

Good output direction

signal tier:
```
branch-gate
```
packet type:
```
ci-signal-hardening
```
or
```
stage-split
```
primary blocker:
```
feedback-speed-confidence
```

next artifact:

CI-signal hardening plan

workflow stage split brief

call out that full packaging likely belongs in a heavier candidate lane, not every merge gate

Example 3: Unreal giant job blob

Input

We have an Unreal pipeline but packaging takes forever and failures show up as one giant log blob.

Good output direction

signal tier: usually
```
nightly-package-candidate
```
unless the user proves every merge truly needs full packaging
packet type:
```
stage-split
```
primary blocker:
```
stage-boundary-blur
```
secondary blocker:
```
feedback-speed-confidence
```
next artifact:
```
workflow stage split brief
```

Example 4: One failing packaging log

Input

Our Unreal Android packaging job failed last night. Here's the AutomationTool output.

Good output direction

packet type:
```
route-to-log-triage
```
primary blocker:
```
single-log-not-pipeline
```
route to
```
game-build-log-triage
```
pass along the failing stage, engine version, target platform, and exact log excerpt

Example 5: Manual nightly/demo candidate process

Input

We already have a quick branch build, but QA needs a nightly Windows + Steam Deck candidate with clear artifact names.

Good output direction

signal tier:
```
nightly-package-candidate
```
packet type:
```
artifact-release
```
or
```
pipeline-setup
```
primary blocker:
```
artifact-release-hygiene
```

next artifact:

artifact/release checklist

pipeline setup plan

keep candidate naming, retention, and consumer handoff explicit

Best practices

Name the signal tier before the packet — branch-gate, nightly/package-candidate, and release/certification work should not share one fake default answer.
Act like a release engineer, not a generic infra lecturer — choose the next packet that reduces repeat pain.
Preserve the log/pipeline boundary — one red build often needs
```
game-build-log-triage
```
before a structural rewrite.
Treat caches as policy — define what is keyed, shared, invalidated, and intentionally regenerated.
Expose stage boundaries — compile, test, cook/package, and publish should not collapse into one unreadable blob.
Keep release context visible — prototype, demo, certification, and launch demand different tradeoffs.
Prefer one next artifact over a sprawling CI/CD manifesto.
Route release-gate policy to
testing-strategies
when the fight is governance, not engine-pipeline shape.

References

references/intake-packets-and-route-outs.md
references/pipeline-patterns.md
references/signal-tiers-and-promotion-lanes.md
Unity Docs — Troubleshoot common issues • Build Automation • Unity Docs
Unity Scriptable Build Pipeline — Cache Server Client
Epic Docs — Packaging Your Project
Epic Docs — Logging in Unreal Engine

game-ci-cd-pipeline

NPX Install

Tags

SKILL.md Content

Game CI/CD Pipeline

When to use this skill

When not to use this skill

Instructions

Step 1: Classify the signal tier first, then choose one primary packet type

Step 2: Gather the minimum credible evidence

Step 3: Choose the signal tier explicitly

Step 4: Classify the primary blocker

Step 5: Run the boundary check

Step 6: Build the packet brief

Step 7: Tailor the packet to the engine and signal tier

Step 8: Ask for the smallest missing packet

Output format

Examples

Example 1: Unity cache superstition

Example 2: Heavy packaging on every branch

Example 3: Unreal giant job blob

Example 4: One failing packaging log

Example 5: Manual nightly/demo candidate process

Best practices

References