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.6 KiB
/smoke-check — Phase 4: Run Manual Smoke Checks
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 4: Run Manual Smoke Checks
In this file:
- Checklist source: name it in the report
- Batch 1 — Core stability
- Batch 2 — Sprint changes and regression
- Batch 3 — Data integrity and performance
- Platform batches: PC, console, mobile
Draw the smoke test checklist from, in priority order (and name the one you used in the report):
- The QA plan's "Smoke Test Scope" section (if QA plan was found in Phase 1)
production/qa/smoke-tests.md(if it exists)tests/smoke/directory contents (if it exists)- The standard fallback list below (used only when none of the above exist)
Name the source you used in the report, on its own line — "Checklist source:
production/qa/smoke-tests.md", or "Checklist source: standard fallback list —
no QA plan scope, no production/qa/smoke-tests.md, no tests/smoke/." The
fallback is a real fallback, so nothing is silently skipped here; what was
missing is that a report drawn from the generic list and one drawn from this
project's own smoke definitions were indistinguishable. /gate-check now
validates a smoke report's claims against the repo, and it cannot weigh them
without knowing what the checklist was drawn from.
Tailor batches 2 and 3 to the actual systems identified from the sprint or QA plan. Replace bracketed placeholders with real mechanic names from the current sprint's stories.
Use AskUserQuestion to batch-verify. Keep to at most 3 calls.
Batch 1 — Core stability (always run): one call, two questions — an empty failure list means nothing unless somebody launched the build.
question: "Did you launch the current build this session?"
multiSelect: false
options:
- "Yes — I launched it and checked the items below"
- "No — I have not launched the current build this session"
question: "Core stability — select any items that FAILED (leave all unselected if everything passed):"
multiSelect: true
options:
- "Game does not launch or crashes before reaching the main menu"
- "New game / session fails to start"
- "Main menu does not respond to inputs"
- "Crash or hang observed during basic navigation"
For any selected item, ask the user to briefly describe what failed before generating the report.
If the build was not launched, the Batch 1 checks could not be executed:
record them as NOT RUN — build not launched this session, skip Batches 2 and
3 and any platform batch (say so — they need a running build), and ignore the
unselected failure list. The verdict is then NOT ASSESSED unless something else
FAILED.
Batch 2 — Sprint changes and regression (always run):
question: "Sprint changes and regression — select any items that FAILED (leave all unselected if everything passed):"
multiSelect: true
options:
- "[Primary mechanic this sprint] — FAILED"
- "[Second notable change this sprint, if any] — FAILED"
- "Regression in a previous sprint's feature — FAILED"
- "Other unexpected breakage observed — FAILED"
For any selected item, ask the user to briefly describe what broke before generating the report.
Batch 3 — Data integrity and performance (run unless quick argument):
question: "Data integrity and performance — select any items that FAILED or were skipped (leave all unselected if everything passed):"
multiSelect: true
options:
- "Save / load — FAILED (data loss or corruption observed)"
- "Save / load — N/A (save system not yet implemented)"
- "Frame rate drops or hitches observed — FAILED"
- "Performance not checked this session"
For any FAILED item selected, ask the user to describe what broke before generating the report.
Record each response verbatim for the Phase 5 report.
Platform Batches (run only if --platform argument was provided):
PC platform (--platform pc or --platform all):
question: "PC Platform — select any items that FAILED (leave all unselected if everything passed):"
multiSelect: true
options:
- "Keyboard controls — FAILED (describe issue after)"
- "Mouse input or cursor visibility — FAILED (describe issue after)"
- "Windowed / fullscreen mode — FAILED (describe issue after)"
- "Resolution change — FAILED (describe issue after)"
For any selected item, ask the user to briefly describe what failed before generating the report.
Console platform (--platform console or --platform all):
question: "Console Platform — select any items that FAILED (leave all unselected if everything passed):"
multiSelect: true
options:
- "Gamepad input — FAILED (describe issue after)"
- "UI outside TV safe zone / text clipped — FAILED (describe what is clipped after)"
- "Keyboard/mouse fallback shown to gamepad user — FAILED (describe after)"
- "Cold start (no prior save) — FAILED (describe issue after)"
For any selected item, ask the user to briefly describe what failed before generating the report.
Mobile platform (--platform mobile or --platform all):
question: "Mobile Platform — select any items that FAILED (leave all unselected if everything passed):"
multiSelect: true
options:
- "Touch controls — FAILED (describe issue after)"
- "Orientation change (portrait ↔ landscape) — FAILED (describe what breaks after)"
- "Background / foreground transition (home button) — FAILED (describe issue after)"
- "Performance / thermal throttling on target device — FAILED (describe after)"
For any selected item, ask the user to briefly describe what failed before generating the report.