用途
该技能面向 Unity 或 Unreal 项目的构建与发布自动化，目标是把混乱的 CI/CD 工作整理成一个有边界、可执行的“游戏流水线包”。它强调先判断当前工作属于哪个信号层级，再选择最小的下一步产物，而不是输出泛泛的 DevOps 文章。
主要能力
技能围绕两个问题展开：第一，本次运行属于哪个信号层级或晋升通道；第二，在该层级内，最小的诚实下一步产物是什么。
信号层级包括：
- branch-gate：快速的合并/提交验证，昂贵的打包应保持例外。
- nightly-package-candidate：定时或手动触发的 QA/评审/演示候选构建，比普通分支 CI 更重。
- release-certification-candidate：受保护、审批密集、需签名、面向商店或认证的候选工作。
可选的主要产物类型包括：pipeline-setup（首次可复现的流水线计划）、stage-split（拆分恢复/构建/测试/烹饪/打包/发布阶段）、cache-policy（明确 Library、Intermediate、Saved、DDC 或包缓存的策略）、preflight-readiness（在昂贵打包前暴露 SDK/签名/工具链/平台前置条件）、artifact-release（修正产物命名、保留、候选与发布区分及 QA 交接）、ci-signal-hardening（在不重写一切的前提下提升反馈速度与信任）、route-to-log-triage（请求主要围绕一个红色构建或日志，应转交日志排查）。
使用方式
技能按步骤执行：
- 先将请求归一化为一个信号层级和一个主要产物类型，并记录引擎、CI 平台、目标平台、发布上下文和证据水平。
- 收集最小可信证据，包括引擎与版本、当前 CI 平台或工作流文件、触发形态、目标平台与发布上下文、重复失败模式、CI 完成后仍需手动执行的步骤、产物命名/保留/审批规则，以及一个近期失败作业或日志。
- 明确选择信号层级，判断哪个通道正在造成信任瓶颈。
- 分类主要阻塞项，可选一个次要阻塞项。阻塞项包括：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。
- 执行边界检查，确认这是结构性流水线问题还是单个失败日志，信号层级是否匹配实际触发/审批/产物问题，是否仍停留在游戏引擎流水线工作内。
- 按固定结构输出“Game CI/CD Brief”，包含产物选择、使用的证据、主要阻塞项、次要阻塞项、推荐流水线形态、引擎与平台检查、推荐下一步产物、转交项和暂不应做的事。
- 根据引擎和信号层级定制建议。对 Unity，关注引擎/编辑器版本固定、Packages/manifest.json 与平台模块稳定性、阶段分离、Library 与包缓存策略；对 Unreal，关注 UBT/UHT、烹饪、打包、发布的分离，插件/模块漂移、资产重定向影响、AutomationTool 可见性，以及 DDC/缓存问题与打包日志根因的区分。
- 若置信度低，只请求能改变决策的最小缺失信息。
适用场景
- Unity 或 Unreal 团队需要从零搭建 CI/CD，但不想过度工程化。
- 流水线反复不稳定、缓慢或不透明，真正问题是工作流结构而非单个日志。
- 构建、烹饪/打包、缓存、产物或发布交接步骤持续破坏对流水线的信任。
- 团队仍手动发布演示/评审/发布构建，需要第一个可复现的流水线包。
- 发布助手、承包商或技术负责人需要紧凑的游戏流水线审计简报。
限制
- 若主要工作是定位某个 Unity/Unreal 构建日志中的首个可操作失败，应转交 game-build-log-triage。
- 若主要工作是跨设计、QA、构建压力和发布时间的里程碑协调，应转交 bmad-gds。
- 若主要工作是运行时性能分析或帧时间瓶颈诊断，应转交 game-performance-profiler。
- 若主要工作是 Steam 页面、愿望单或发布商店运营，应转交 steam-store-launch-ops。
- 若主要工作是普通 Web/后端仓库的通用 CI/CD，应使用更广泛的 DevOps 技能。
- 输出应保持约 300-550 词，除非用户要求更多；推荐一个下一步产物，而非完整平台重写。
- 若证据薄弱，应保持低置信度，优先转交日志排查或选择窄范围产物，而非假装进行完整重设计。