game-ci-cd-pipeline · diff

v1.2.0 to v1.2.0

1 added, 1 removed. Audit A to A.

---

name: game-ci-cd-pipeline

description: >

Turn messy Unity or Unreal build/release automation into one bounded game-pipeline

packet after naming the signal tier first: fast branch-gate CI, nightly/package-

candidate builds, or release/certification candidates. Use when a game team needs

to design or repair GitHub Actions, Unity Build Automation, Jenkins, TeamCity, or

similar CI for engine builds — especially when they mention flaky packaging, cache

superstition, giant build-job blobs, slow cook / package cycles, artifact confusion,

SDK/signing drift, or manual candidate promotion that should become reproducible.

Route one red log first-pass diagnosis to `game-build-log-triage`.

allowed-tools: Bash Read Write Edit Glob Grep

compatibility: >

Best for Unity or Unreal repositories, workflow files, job logs, release checklists,

platform/toolchain notes, or manual build procedures that need to become a reliable

pipeline. Works as a pipeline audit-and-brief workflow, not an automatic deployer or

secret-rotation system.

metadata:

tags: game-development, unity, unreal, ci-cd, github-actions, build-pipeline, release-engineering, release-candidates

version: "1.2.0"

- source: akillness/oh-my-skills

+ source: akillness/jeo-skills

hardening: 2026-04-19

ratchet: 2026-04-20

---

# 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:

1. **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

2. **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/intake-packets-and-route-outs.md)

- [references/pipeline-patterns.md](references/pipeline-patterns.md)

- [references/signal-tiers-and-promotion-lanes.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

engine: Unity | Unreal | mixed | 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:

1. Is this a structural pipeline question or just a failing log?

2. Does the chosen signal tier match the actual trigger/approval/artifact problem?

3. Is the best next artifact one of the packet types above?

4. Are you staying inside game-engine pipeline work instead of drifting into generic web-app DevOps?

5. 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

## 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:

1. current workflow file or job outline

2. trigger shape (PR/push vs schedule/manual vs protected release lane)

3. engine version and target platforms

4. one recent failed job/log if the issue may be `single-log-not-pipeline`

5. current artifact naming / retention / approval pattern

6. 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` or `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` or `pipeline setup plan`

- keep candidate naming, retention, and consumer handoff explicit

## Best practices

1. **Name the signal tier before the packet** — branch-gate, nightly/package-candidate, and release/certification work should not share one fake default answer.

2. **Act like a release engineer, not a generic infra lecturer** — choose the next packet that reduces repeat pain.

3. **Preserve the log/pipeline boundary** — one red build often needs `game-build-log-triage` before a structural rewrite.

4. **Treat caches as policy** — define what is keyed, shared, invalidated, and intentionally regenerated.

5. **Expose stage boundaries** — compile, test, cook/package, and publish should not collapse into one unreadable blob.

6. **Keep release context visible** — prototype, demo, certification, and launch demand different tradeoffs.

7. **Prefer one next artifact** over a sprawling CI/CD manifesto.

8. **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/intake-packets-and-route-outs.md)

- [references/pipeline-patterns.md](references/pipeline-patterns.md)

- [references/signal-tiers-and-promotion-lanes.md](references/signal-tiers-and-promotion-lanes.md)

- [Unity Docs — Troubleshoot common issues • Build Automation • Unity Docs](https://docs.unity.com/en-us/build-automation/check-build-results/troubleshoot-build-failures/overview)

- [Unity Scriptable Build Pipeline — Cache Server Client](https://docs.unity3d.com/Packages/com.unity.scriptablebuildpipeline@2.0/manual/CacheServerClient.html)

- [Epic Docs — Packaging Your Project](https://dev.epicgames.com/documentation/en-us/unreal-engine/packaging-your-project)

- [Epic Docs — Logging in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/logging-in-unreal-engine)