mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios
synced 2026-04-21 21:37:19 +00:00
a73ff759c9
- Add CCGS Skill Testing Framework: self-contained QA layer with 72 skill specs, 49 agent specs, catalog.yaml, quality-rubric.md, templates, README, CLAUDE.md - Add /skill-improve: test-fix-retest loop covering static + category checks - Add 4 missing skills: /art-bible, /asset-spec, /day-one-patch, /security-audit - Add /skill-test category mode (Phase 2D) with quality rubric evaluation - Extend /skill-test audit to cover agent specs alongside skill specs - Update all skill-test and skill-improve path refs to CCGS Skill Testing Framework/ - Remove stale tests/skills/ directory (superseded by CCGS Skill Testing Framework) - Add director gate intensity modes (full/lean/solo) to gate-check and related skills Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
80 lines
5.4 KiB
Markdown
80 lines
5.4 KiB
Markdown
# 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`
|