Skills
skills/akillness/oh-my-skills/game-ci-cd-pipeline

game-ci-cd-pipeline

Installation
SKILL.md

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:

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.

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:

  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:

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

  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

Weekly Installs
46
Repository
akillness/oh-my-skills
GitHub Stars
11
First Seen
Today
Security Audits
Gen Agent Trust HubPass
SocketPass
SnykWarn