smoke-check skill

!bash "${CLAUDESKILLDIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation,qa.level,testing.strict

Smoke Check

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

Every AskUserQuestion call follows .claude/docs/automation-modes.md (collaborative asks always · guided major-only · autonomous logs and proceeds; automationalwaysask categories always prompt).

qa.level: at minimal, smoke-check is optional — if run, a FAIL is advisory and never blocks hand-off; at standard, it is required before a phase transition; at full, before every commit. This sits in front of the Phase 6 testing.strict.config resolution (which only matters once a smoke run gates). Distinct axis from workflow.

Parse Arguments

Arguments can be combined: /smoke-check sprint --platform console

Base mode (first argument, default: sprint):

• sprint — full smoke check against the current sprint's stories
• quick — skip coverage scan (Phase 3) and Batch 3; use for rapid re-checks

Platform flag (--platform, default: none):

platform certification requirements)

• --platform pc — add PC-specific checks (keyboard, mouse, windowed mode)
• --platform console — add console-specific checks (gamepad, TV safe zones,

battery/thermal behaviour)

• --platform mobile — add mobile-specific checks (touch, portrait/landscape,

• --platform all — add all platform variants; output per-platform verdict table

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.

Phase 1: Detect Test Setup

Before running anything, understand the environment:

1. Config coherence: run bash .claude/scripts/project-coherence.sh.

It compares what project.yaml declares against the real project file, the installed engine binary, and the files commands. name. This runs first because two of its checks are about this skill's own inputs: a commands.test naming a runner that does not exist, or a commands.build naming an export preset with no exportpresets.cfg, will fail here and read as a broken build rather than as broken config.

Report any [DIFFERS] lines in the report's Environment section. They do not by themselves decide the verdict -- but a smoke check run against a project whose declared engine is not the installed one is worth saying out loud.

that tests/ does. Check tests/unit/, tests/integration/ and tests/smoke/ for actual test files. If none are found, deliver a NOT ASSESSED verdict — do not merely stop. "Smoke check: NOT ASSESSED — no game tests found under tests/unit|integration|smoke. Run /test-setup to scaffold the testing infrastructure, or point me at where tests live." Then stop.

1. Test framework check: verify that game test files exist — not merely

A bare halt is the wrong shape here.

This is the state with the least information about build health, so it is

the last one that should exit without a verdict: the caller gets no

machine-readable outcome, and "the skill said nothing" is easy to read as

"nothing was wrong". Replacing a wrong verdict with no verdict is not an

improvement either — the honest result is the one that names what could not

be established.

Do not gate on tests/ existing. /test-setup creates tests/unit/

and tests/integration/ with placeholder files, so the directory tree is

present on any project that ran setup — whether or not a single game test

was ever written. Count actual test files instead. That is not

hypothetical: a fixture with no build and zero game tests passed this step

and went on to score PASS WITH WARNINGS.

referencing tests. Note in the report whether CI is configured.

1. CI check: check whether .github/workflows/ contains a workflow file

is absent or empty (including when project.yaml has no engine: block), fall back to the Engine: value in .claude/docs/technical-preferences.md (a [TO BE CONFIGURED] value means not configured). Store this for test command selection in Phase 2.

1. Engine detection: read engine.name from project.yaml; if that key

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).

1. Smoke test list: check whether production/qa/smoke-tests.md or

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."

1. QA plan check: glob production/qa/qa-plan-*.md and take the most

Report findings before proceeding: "Environment: [engine]. Test directory: [found / not found]. CI configured: [yes / no]. QA plan: [path / not found]."

Phase 2: Run Automated Tests

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 can run tests headlessly via shell. Do not skip to reading artifacts.

First confirm the Unity Test Framework is installed. A project without it does not fail cleanly — it hangs until something kills it, which is the observation the old "Unity cannot test headlessly" advice was generalised from:

grep -q 'com.unity.test-framework' Packages/manifest.json && echo present || echo ABSENT

If ABSENT, report NOT ASSESSED — Unity Test Framework not installed and give the one-line fix (add com.unity.test-framework to Packages/manifest.json). Do not fall through to reading stale artifacts — an unknown-age XML reported as a pass is worse than no gate.

If present, run the suite with an explicit timeout:

timeout 900 "<Unity.exe>" -batchmode -runTests -projectPath . -testPlatform EditMode -testResults test-results/results.xml