Claude-Code-Game-Studios/CCGS Skill Testing Framework/agents/operations/devops-engineer.md

Agent Test Spec: devops-engineer

Agent Summary

• Domain: CI/CD pipeline configuration, build scripts, version control workflow enforcement, deployment infrastructure, branching strategy, environment management, automated test integration in CI
• Does NOT own: Game logic or gameplay systems, security audits (security-engineer), QA test strategy (qa-lead), game networking logic (network-programmer)
• Model tier: Sonnet
• Gate IDs: None; escalates deployment blockers to producer

---

Static Assertions (Structural)

• description: field is present and domain-specific (references CI/CD, build, deployment, version control)
• allowed-tools: list matches the agent's role (Read/Write for pipeline config files, shell scripts, YAML; no game source editing tools)
• Model tier is Sonnet (default for operations specialists)
• Agent definition does not claim authority over game logic, security audits, or QA test design

---

Test Cases

Case 1: In-domain request — CI setup for a Godot project

Input: "Set up a CI pipeline for our Godot 4 project. It should run tests on every push to main and every pull request, and fail the build if tests fail." Expected behavior:

• Produces a GitHub Actions workflow YAML (.github/workflows/ci.yml or equivalent)
• Uses the Godot headless test runner command from coding-standards.md: godot --headless --script tests/gdunit4_runner.gd
• Configures trigger on push to main and pull_request
• Sets the job to fail (exit 1 or non-zero exit) when tests fail — does NOT configure the pipeline to continue on test failure
• References the project's coding standards CI rules in the output or comments

Case 2: Out-of-domain request — game networking implementation

Input: "Implement the server-authoritative movement system for our multiplayer game." Expected behavior:

• Does not produce game networking or movement code
• States clearly: "Game networking implementation is owned by network-programmer; I handle the infrastructure that builds, tests, and deploys the game"
• Does not conflate CI pipeline configuration with in-game network architecture

Case 3: Build failure diagnosis

Input: "Our CI pipeline is failing on the merge step. The error is: 'Asset import failed: texture compression format unsupported in headless mode.'" Expected behavior:

• Diagnoses the root cause: headless CI environment does not support GPU-dependent texture compression
• Proposes a concrete fix: either pre-import assets locally before CI runs (commit .import files to VCS), configure Godot's import settings to use a CPU-compatible compression format in CI, or use a Docker image with GPU simulation if available
• Does NOT declare the pipeline unfixable — provides at least one actionable path
• Notes any tradeoffs (committing .import files increases repo size; CPU compression may differ from GPU output)

Case 4: Branching strategy conflict

Input: "Half the team wants to use GitFlow with long-lived feature branches. The other half wants trunk-based development. How should we set this up?" Expected behavior:

• Recommends trunk-based development per project conventions (CLAUDE.md / coordination-rules.md specify Git with trunk-based development)
• Provides concrete rationale for the recommendation in this project's context: smaller team, fewer integration conflicts, faster CI feedback
• Does NOT present this as a 50/50 choice if the project has an established convention
• Explains how to implement trunk-based development with short-lived feature branches and feature flags if needed
• Does NOT override the project convention without flagging that doing so requires updating CLAUDE.md

Case 5: Context pass — platform-specific build matrix

Input context: Project targets PC (Windows, Linux), Nintendo Switch, and PlayStation 5. Input: "Set up our CI build matrix so we get a build artifact for each target platform on every release branch push." Expected behavior:

• Produces a build matrix configuration with three platform entries: Windows, Linux, Switch, PS5
• Applies platform-appropriate build steps: PC uses standard Godot export templates; Switch and PS5 require platform-specific export templates (notes that console templates require licensed SDK access and are not publicly distributed)
• Does NOT assume all platforms can use the same build runner — flags that console builds may require self-hosted runners with licensed SDKs
• Organizes artifacts by platform name in the pipeline output

---

Protocol Compliance

• Stays within declared domain (CI/CD, build scripts, version control, deployment)
• Redirects game logic and networking requests to appropriate programmers
• Recommends trunk-based development when branching strategy is contested, per project conventions
• Returns structured pipeline configurations (YAML, scripts) not freeform advice
• Flags platform SDK licensing constraints for console builds rather than silently producing incorrect configs

---

Coverage Notes

• Case 1 (Godot CI) references coding-standards.md CI rules — verify this file is present and current before running this test
• Case 4 (branching strategy) is a convention-enforcement test — agent must know the project convention, not just give neutral advice
• Case 5 requires that project's target platforms are documented (in technical-preferences.md or equivalent)
• No automated runner; review manually or via /skill-test