smoke-check — Claude Code skill: QA gate and setup
Runs automated tests and critical-path checks before a build goes to QA. It records a verdict and writes a smoke report after approval.
npx skills add Donchitos/Claude-Code-Game-Studios --skill smoke-check -a claude-codeWhat smoke-check does
smoke-check is a gate between implementation work and QA hand-off. It detects the test setup, runs the automated suite, checks coverage gaps, and asks the developer to verify critical paths manually. The report is written to production/qa/smoke-[date].md.
The default sprint mode checks the current sprint’s stories. quick skips the coverage scan and Batch 3 for a follow-up run after a specific failure is fixed. Add --platform pc, --platform console, --platform mobile, or --platform all to include platform checks; all also produces a verdict table for each platform. Manual checks use AskUserQuestion, and the report cannot be created until explicit approval is given.
The skill reports failures rather than editing source or test files. With qa.level: minimal, a FAIL is advisory; standard requires the check before a phase transition, while full requires it before every commit. Check qa.level first, because it determines whether a failed smoke run blocks the QA hand-off.
What it helps with
- gate a build before QA hand-off
- run the project’s automated test suite
- scan for missing test coverage
- verify critical paths with the developer
- write a PASS/FAIL smoke report
Example prompts for the agent
- Run
/smoke-checkfor the full check of the current sprint. - Run
/smoke-check quickafter fixing a specific failure. - Check the console build with
/smoke-check sprint --platform console.
How to install smoke-check
1Skills CLI (Vercel)
npx skills add Donchitos/Claude-Code-Game-Studios --skill smoke-check -a claude-code2Manually: put the files in place
~/.claude/skills/smoke-check/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/smoke-check/
1Skills CLI (Vercel)
npx skills add Donchitos/Claude-Code-Game-Studios --skill smoke-check -a codex2Manually: put the files in place
.agents/skills/smoke-check/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add Donchitos/Claude-Code-Game-Studios --skill smoke-check -a cursor2Manually: put the files in place
.cursor/skills/smoke-check/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install Donchitos/Claude-Code-Game-Studios smoke-check2Manually: put the files in place
.github/skills/smoke-check/SKILL.md1Skills CLI (Vercel)
npx skills add Donchitos/Claude-Code-Game-Studios --skill smoke-check -a gemini-cli2Platform CLI
gemini skills install https://github.com/Donchitos/Claude-Code-Game-Studios --path .claude/skills/smoke-checkManually: put the files in place
.devin/skills/smoke-check/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add Donchitos/Claude-Code-Game-Studios --skill smoke-check -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about smoke-check
How do I install smoke-check in Claude Code?
Run npx skills add Donchitos/Claude-Code-Game-Studios --skill smoke-check -a claude-code, then run npx skills add Donchitos/Claude-Code-Game-Studios --skill smoke-check -a claude-code again. The skill file is at ~/.claude/skills/smoke-check/SKILL.md.
What does smoke-check do?
It detects the test setup, runs automated tests, checks coverage and critical paths, and prepares a smoke report. The skill asks for approval before writing that report.
What is the difference between sprint and quick?
sprint runs the full check against the current sprint’s stories. quick skips the coverage scan and Batch 3, so it is suited to a follow-up run after a failure has been fixed.
Source text
SKILL.md · MIT
---
name: smoke-check
description: "Critical-path smoke gate before QA hand-off — runs the automated suite. A failed check means the build is not QA-ready."
argument-hint: "[sprint | quick | --platform pc|console|mobile|all]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, AskUserQuestion, Bash(bash "*/.claude/skills/smoke-check/../../hooks/yaml-helper.sh" resolve_config *), Bash(bash .claude/scripts/project-coherence.sh*), Bash(command -v *), Bash(uname -s), Bash(godot --headless --path . --import), Bash(timeout 900 godot --headless *), Bash(timeout 1800 godot --headless *), Bash(grep -q 'com.unity.test-framework' Packages/manifest.json), Bash(echo present), Bash(echo ABSENT)
model: sonnet
---
!`bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation,workflow,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;
`automation_always_ask` categories always prompt).
**`qa.level`**: at `minimal`, smoke-check is **optional** — if
run, a FAIL is advisory and never blocks hand-off, and a project with no game
tests is checked by its build, launch and critical paths alone (Phase 1 step 1); 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 pc` — add PC-specific checks (keyboard, mouse, windowed mode)
- `--platform console` — add console-specific checks (gamepad, TV safe zones,
platform certification requirements)
- `--platform mobile` — add mobile-specific checks (touch, portrait/landscape,
battery/thermal behaviour)
- `--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
**Read `references/1-detect-setup.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
## Phase 2: Run Automated Tests
**Read `references/2-run-tests.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
## Phase 3: Check Test Coverage
**Read `references/3-coverage.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
## Phase 4: Run Manual Smoke Checks
**Read `references/4-manual-checks.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
## Phase 5: Generate Report
**Read `references/5-report.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
## Phase 6: Write and Gate
**Read `references/6-write-gate.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
## Collaborative Protocol
**Applies in `collaborative` mode (the default).** For `guided` and
`autonomous` modes, see `.claude/docs/automation-modes.md` — the rules below
describe what collaborative mode requires, not universal behavior.
- **Never treat NOT RUN as automatic FAIL** — record it as NOT RUN and let
the developer confirm status manually. Unconfirmed NOT RUN yields **NOT
ASSESSED**, not FAIL — and not a pass verdict either.
- **Never auto-fix failures** — report them and state what must be resolved.
Do not attempt to edit source code or test files.
- **PASS WITH WARNINGS does not block QA hand-off** — it records advisory
gaps for `/story-done` to follow up on.
- **`quick` argument** skips Phase 3 (coverage scan) and Phase 4 Batch 3.
Use it for rapid re-checks after fixing a specific failure.
- Use `AskUserQuestion` for all manual smoke check verification.
- **Never write the report without asking** — Phase 6 requires explicit
approval before any file is created.
© Donchitos · MIT · Donchitos/Claude-Code-Game-Studios