adopt
Brownfield onboarding — audits existing project artifacts for template format compliance (not just existence), classifies gaps by impact, and produces a…
Run the critical path smoke test gate before QA hand-off. Executes the automated test suite, verifies core functionality, and produces a PASS/FAIL report. Run after a sprint's stories are implemented and before manual QA begins. A failed smoke check means the build is not ready
$ npx -y skills add Donchitos/Claude-Code-Game-Studios --skill smoke-check --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/smoke-checkContext preview
The summary Claude sees to decide when to auto-load this skill.
Run the critical path smoke test gate before QA hand-off. Executes the automated test suite, verifies core functionality, and produces a PASS/FAIL report. Run after a sprint's stories are implemented and before manual QA begins. A failed smoke check means the build is not ready
name: smoke-check description: "Run the critical path smoke test gate before QA hand-off. Executes the automated test suite, verifies core functionality, and produces a PASS/FAIL report. Run after a sprint's stories are implemented and before manual QA begins. A failed smoke check means the build is not ready for QA." argument-hint: "[sprint | quick | --platform pc|console|mobile|all]" user-invocable: true allowed-tools: Read, Glob, Grep, Bash, Write, AskUserQuestion model: sonnet
This skill is the gate between "implementation done" and "ready for QA hand-off". It runs the automated test suite, checks for test coverage gaps, batch-verifies critical paths with the developer, and produces a PASS/FAIL report.
The rule is simple: **a build that fails smoke check does not go to QA.** Handing a broken build to QA wastes their time and demoralises the team.
**Output:** `production/qa/smoke-[date].md`
---
Arguments can be combined: `/smoke-check sprint --platform console`
**Base mode** (first argument, default: `sprint`):
**Platform flag** (`--platform`, default: none):
platform certification requirements)
battery/thermal behaviour)
If `--platform` is provided, Phase 4 adds platform-specific batches and Phase 5 outputs a per-platform verdict table in addition to the overall verdict.
---
Before running anything, understand the environment:
1. **Test framework check**: verify `tests/` directory exists. If it does not: "No test directory found at `tests/`. Run `/test-setup` to scaffold the testing infrastructure, or create the directory manually if tests live elsewhere." Then stop.
2. **CI check**: check whether `.github/workflows/` contains a workflow file referencing tests. Note in the report whether CI is configured.
3. **Engine detection**: read `.claude/docs/technical-preferences.md` and extract the `Engine:` value. Store this for test command selection in Phase 2.
4. **Smoke test list**: check whether `production/qa/smoke-tests.md` or `tests/smoke/` exists. If a smoke test list is found, load it for use in Phase 4. If neither exists, smoke tests will be drawn from the current QA plan (Phase 4 fallback).
5. **QA plan check**: glob `production/qa/qa-plan-*.md` and take the most recently modified file. If found, note the path — it will be used in Phase 3 and Phase 4. If not found, note: "No QA plan found. Run `/qa-plan sprint` before smoke-checking for best results."
Report findings before proceeding: "Environment: [engine]. Test directory: [found / not found]. CI configured: [yes / no]. QA plan: [path / not found]."
---
Attempt to run the test suite via Bash. Select the command based on the engine detected in Phase 1:
**Godot 4:**
godot --headless --script tests/gdunit4_runner.gd 2>&1
If the GDUnit4 runner script does not exist at that path, try:
godot --headless -s addons/gdunit4/GdUnitRunner.gd 2>&1
If neither path exists, note: "GDUnit4 runner not found — confirm the runner path for your test framework."
**Unity:** Unity tests require the editor and cannot be run headlessly via shell in most environments. Check for recent test result artifacts:
# List most recent test results (bash) — on Windows PowerShell use the fallback below ls -t test-results/ 2>/dev/null | head -5 \ || powershell -Command "Get-ChildItem test-results/ -ErrorAction SilentlyContinue | Sort-Object LastWriteTime -Descending | Select-Object -First 5 -ExpandProperty Name"
If test result files exist (XML or JSON), read the most recent one and parse PASS/FAIL counts. If no artifacts exist: "Unity tests must be run from the editor or CI pipeline. Please confirm test status manually before proceeding."
**Unreal Engine:**
# List most recent Unreal automation logs (bash) — on Windows PowerShell use the fallback below
ls -t Saved/Logs/ 2>/dev/null | grep -i "test\|automation" | head -5 \
|| powershell -Command "Get-ChildItem Saved/Logs/ -ErrorAction SilentlyContinue | Where-Object { $_.Name -match 'test|automation' } | Sort-Object LastWriteTime -Descending | Select-Object -First 5 -ExpandProperty Name"If no matching log found: "UE automation tests must be run via the Session Frontend or CI pipeline. Please confirm test status manually."
**Unknown engine / not configured:** "Engine not configured in `.claude/docs/technical-preferences.md`. Run `/setup-engine` to specify the engine, then re-run `/smoke-check`."
**If the test runner is not available in this environment** (engine binary not on PATH, runner script not found, etc.), report clearly:
"Automated tests could not be executed — engine binary not found on PATH. Status will be recorded as NOT RUN. Confirm test results from your local IDE or CI pipeline. Unconfirmed NOT RUN is treated as PASS WITH WARNINGS, not FAIL — the developer must manually confirm results."
Do not treat NOT RUN as an automatic FAIL. Record it as a warning. The developer's manual confirmation in Phase 4 can resolve it.
Parse runner output and extract:
---
Draw the story list from, in priority order: 1. The QA plan found in Phase 1 (its Test Summary table lists expected test file paths per story) 2. The current sprint plan from `producti
Turn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.
Repo: Donchitos/Claude-Code-Game-Studios
Brownfield onboarding — audits existing project artifacts for template format compliance (not just existence), classifies gaps by impact, and produces a…
Creates an Architecture Decision Record (ADR) documenting a significant technical decision, its context, alternatives considered, and consequences. Every major…
Validates completeness and consistency of the project architecture against all GDDs. Builds a traceability matrix mapping every GDD technical requirement to…
Guided, section-by-section Art Bible authoring. Creates the visual identity specification that gates all asset production. Run after /brainstorm is approved…
Audits game assets for compliance with naming conventions, file size budgets, format standards, and pipeline requirements. Identifies orphaned assets, missing…
Generate per-asset visual specifications and AI generation prompts from GDDs, level docs, or character profiles. Produces structured spec files and updates the…