/smoke-test

name: smoke-test
description: "Launch the app and verify hands-on that it works, falling back to an existing integration suite. Use when the user asks to \"smoke test\", \"verify it works\", \"try it out\", or \"check it in the browser\"."

Smoke Test

Launch the app and hands-on verify that it works by interacting with it. Every smoke test is a concrete interaction with the running app: navigating a screen, clicking a control, filling a form, running a CLI command, and observing the result.

Step 1: Determine Scope

Resolve scope using the first match:

1. **User-specified** — the user says what to test. Use that. 2. **PR** — a PR URL or number is provided. Fetch the PR details (title, description, changed files, comments) and read the changed code. 3. **Conversation context** — prior conversation contains recent work (a feature, fix, or refactor). Extract what changed, where it lives, and expected behavior. 4. **App-level discovery** — fresh context with no prior work. Examine the project (entry points, routes, commands, README) to identify the app's core user-facing flows. Design tests that verify the app launches and its primary functionality works end-to-end.

Step 2: Determine Testing Approach

Always check for project-specific testing skills or MCP tools first. Use the fallbacks below when nothing project-specific is available:

• **Web app** → `/agent-browser` skill if available, otherwise `claude-in-chrome` MCP
• **UI/native app** → `computer-use` MCP
• **CLI tool** → direct terminal execution
• **Library with no entry point** → report that smoke testing is not applicable and stop, unless the scope changes a check's configuration; then use direct terminal execution

Step 3: Run `/test-run-rules` Skill

Run the `/test-run-rules` skill to load the rules for launching and driving the app.

Step 4: Plan Smoke Tests

Before drafting tests, check whether there is something to exercise:

• **The scope changes a check's configuration** (linter, formatter, type checker, or CI gate rules) — for that part of the scope, the check itself is the surface; plan tests against it and run them via the CLI Path in Step 5. Export the tree carrying the change to a scratch directory outside the checkout, add input there that each changed rule should flag or accept, and run the check on it. Pair each case with the same input under the configuration at the ref the resolved scope is measured against as its control, so a verdict the old configuration also produces is not credited to the change. Write the control configuration into the exported tree beside the configuration it stands in for. Credit a run's verdict only when the check processed a nonzero number of inputs; otherwise fix its setup and rerun, and report the case inconclusive only when no fix gets the check to process any input. Reach the check's installed toolchain and plugins from the scratch directory without installing into or modifying the checkout; when the check cannot run there, report the case unverified. When the change adds or narrows a suppression and the check reports unused suppressions, add a case with the suppressed cause removed and confirm the check reports the stale suppression.
• **No user-visible change in the resolved scope** — look for an existing integration test target that covers the change and is not part of the default test suite (so it hasn't already run in this session). If one exists, run it via the Integration Test Path in Step 5. If nothing exists, report that there is no interactive surface to verify and no separate integration suite to fall back on, then stop.
• **Required infrastructure cannot be stood up in this session** (backend service, auth provider, external dependency) — look for a stub under the test run rules before reporting blocked. When a stub works, record its response shapes and state transitions in the Setup contract's **Mock boundaries** item, along with the re-install condition for a call-site stub, and the PID and port of any stub process in **Owned cleanup**, then carry on with the plan. When the rules leave the scenario blocked, report blocked, naming what is missing and what was tried, then stop.
• **A test needs privileged state or a second participant** (an entitlement or plan tier, an elevated role, seed data, a second concurrent client or session) — provision it under the test run rules. Keep the test in the plan once provisioning succeeds, and record the granted state in the Setup contract's **Test identity** item and every session, role, and record this run creates in **Owned cleanup**. Drop the test to unverified only after an attempt failed.

Otherwise, design targeted smoke tests. Each test should:

1. Exercise a specific flow from the determined scope 2. Verify the happy path works end-to-end 3. Check one obvious edge case if applicable

Confirm any control, command, or other affordance a test names exists in the code before writing the test: search for the API that would implement it rather than inferring it from what the feature does. Where it cannot be confirmed, write the test against the outcome to verify and leave the affordance to be found during execution.

Confirm as well that the surface accepts a test's action in the state the test sets up. When the code refuses or swallows that action there, drive a state or entry point where the action goes through, or make the refusal itself the observation. When a scenario claims an affordance is available in a state, drive each such affordance in that state to its first observable effect and make that effect the pass condition; a refusal or swallowed action there fails the scenario. For an affordance whose effect is not cleanly undoable, stop at its confirmation step and cancel it. When the affordance has no confirmation step, act on a record this run created, record it in **Owned cleanup**, and carry any write to a shared external system through the test run rules' write sequence; plan the scenario as unver