Fix release for 1.1.2: the 14 longest skills keep their later phases after a compaction, a question nobody answered is never taken as an answer, settings read the same from a subfolder, the commit check works for a project in a subfolder of a larger repository, every skill opens with a title, and the shipped allow rules no longer approve deleting a branch or writing files without asking. Details in CHANGELOG.md; upgrade steps in UPGRADING.md (v1.1.2 → v1.1.3). Refs #83 Refs #133 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185en4t76fPn7315q4c3nko
5.4 KiB
/smoke-check — Phase 1: Detect Test Setup
Part of
/smoke-check.SKILL.mdnames when to read this file; the settings it resolved and the rules under its later headings still apply here.
Phase 1: Detect Test Setup
Before running anything, understand the environment:
-
Config coherence: run
bash .claude/scripts/project-coherence.sh.It compares what
project.yamldeclares against the real project file, the installed engine binary, and the filescommands.*name. This runs first because two of its checks are about this skill's own inputs: acommands.testnaming a runner that does not exist, or acommands.buildnaming an export preset with noexport_presets.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. -
Test framework check: verify that game test files exist — not merely that
tests/does. Check the engine's test root (from step 3; the table is in.claude/docs/directory-structure.md— Godottests/unit/andtests/integration/, UnityAssets/Tests/, UnrealSource/*/Private/Tests/) andtests/smoke/for actual test files. A test file is one the engine's test runner executes — a*_test.gdsuite, a C# test class, an Unreal automation test source. Markdown checklists do not count:/test-setupalways writestests/smoke/critical-paths.md, and counting it would hide exactly the zero-test state this step exists to catch. If none are found atqa.level: minimal, tests are waived at this level: record the automated row asWAIVED — qa.level: minimal, no game tests, skip the test run in Phase 2 and all of Phase 3 (say so in one line each), run Phase 2's build check, and go on to Phase 4 — the build check and the launch and critical-path checks are the smoke check at this level, so a project with no tests can still reach PASS, but never without a run: a Batch 1 answer that the build was not launched this session leaves the verdict NOT ASSESSED. If none are found atstandardorfull, deliver a NOT ASSESSED verdict — do not merely stop. "Smoke check: NOT ASSESSED — no game tests found under [the test root] ortests/smoke/. Run/test-setupto scaffold the testing infrastructure, or point me at where tests live." Then stop.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-setupcreatestests/unit/andtests/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; gated on the directory, a project with no build and zero game tests passes this step. -
CI check: check whether
.github/workflows/contains a workflow file referencing tests. Note in the report whether CI is configured. -
Engine detection: read
engine.namefromproject.yaml; if that key is absent or empty (including whenproject.yamlhas noengine:block), fall back to theEngine:value in.claude/docs/technical-preferences.md(a[TO BE CONFIGURED]value means not configured). Store this for test command selection in Phase 2.Then find the editor executable — none of the three engines installs onto
PATHby default on Windows or macOS, so a baregodotthat does not resolve says nothing about whether the engine is installed. Take the first that resolves (the file exists, orcommand -vfinds it): the executablecommands.testnames (its quoted path or first word), else the editorengine.pathrecords, else the engine's name onPATH(godot). Use it wherever Phase 2 writesgodotor"<Unity editor>", quoting a path with a space; on Unreal,<UE root>isengine.path. If none resolves, the test runner is not available (Phase 2) — on Godot,NOT ASSESSED — Godot executable not found (commands.test, engine.path, PATH). -
Smoke test list: check whether
production/qa/smoke-tests.mdortests/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). -
QA plan check: glob
production/qa/qa-plan-*.mdand 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 sprintbefore smoke-checking for best results." (Atworkflow: minimal, which has no sprints, a QA plan is optional — say so rather than recommend one.)
Report findings before proceeding: "Environment: [engine]. Editor: [the resolved executable / not found]. Test directory: [found / not found]. CI configured: [yes / no]. QA plan: [path / not found]."