smoke-test
Smoke Test
Launch the app and hands-on verify that it works. Not unit/integration tests.
Step 1: Determine Scope
Resolve scope using the first match:
- User-specified — the user says what to test. Use that.
- PR — a PR URL or number is provided. Fetch the PR details (title, description, changed files, comments) and read the changed code.
- Conversation context — prior conversation contains recent work (a feature, fix, or refactor). Extract what changed, where it lives, and expected behavior.
- 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-browserskill if available, otherwiseclaude-in-chromeMCP - UI/native app →
computer-useMCP - CLI tool → direct terminal execution
- Library with no entry point → report that smoke testing is not applicable and stop
Step 3: Plan Smoke Tests
Design targeted smoke tests based on the scope. Each test should:
- Exercise a specific flow from the determined scope
- Verify the happy path works end-to-end
- Check one obvious edge case if applicable
Output the plan as text:
Smoke Test Plan:
1. [Test description] — verifies [what]
2. [Test description] — verifies [what]
3. [Test description] — verifies [what]
Approach: [agent-browser / claude-in-chrome / computer-use / terminal]
Dev server command: [command]
Step 4: Execute
If a project-specific testing skill or MCP tool was identified in Step 2, use that. The paths below are fallbacks.
Web App Path
Start the dev server if not already running. Wait for it to be ready. If /agent-browser is available, run the /agent-browser skill. Otherwise, use claude-in-chrome MCP to interact with the app.
Core verification loop per test:
- Navigate to the relevant page/route
- Snapshot and verify expected UI elements exist
- Interact (fill forms, click buttons, navigate)
- Re-snapshot and verify the expected outcome
- Record pass/fail
Close the browser session and stop the dev server when done.
UI/Native App Path
Launch the app. Use computer-use MCP to interact with the UI.
Core verification loop per test:
- Capture the UI state
- Interact with the relevant controls
- Re-capture and verify the expected outcome
- Record pass/fail
CLI Path
Run commands directly.
Core verification loop per test:
- Run the command with expected inputs
- Check stdout/stderr for expected output
- Verify side effects (files created, data changed)
- Record pass/fail
Step 5: Report
Present a summary:
Smoke Test Results:
- [PASS] Test 1: description
- [FAIL] Test 2: description — [what went wrong]
- [PASS] Test 3: description
Overall: X/Y passed
If any test failed, include the relevant snapshot, screenshot, or output showing the failure.
Check your task list for remaining tasks and proceed.
Rules
- Always clean up: close browser sessions, stop dev servers started by this skill.
- Never modify code. This skill is read-only verification. If a test fails, report the failure — do not attempt to fix it.
- If the dev server fails to start, report the error and stop.
- Keep tests focused on the determined scope.
- Use the Monitor tool to tail app logs for errors or warnings while verifying, so backend failures surface alongside UI checks.
- After the last UI interaction, perform one additional log read or status check before reporting. Pending
Monitorevents that arrive after the agent emits final text are dropped, so the extra action gives them time to land. Matters most when this skill runs inside a subagent (e.g., from/polish-code). - To diagnose failures, run the
/investigateskill on the smoke test report.
More from tobihagemann/turbo
find-dead-code
Find dead code using parallel subagent analysis and optional CLI tools, treating code only referenced from tests as dead. Use when the user asks to \"find dead code\", \"find unused code\", \"find unused exports\", \"find unreferenced functions\", \"clean up dead code\", or \"what code is unused\". Analysis-only — does not modify or delete code.
30simplify-code
Run a multi-agent review of changed files for reuse, quality, efficiency, and clarity issues followed by automated fixes. Use when the user asks to \"simplify code\", \"review changed code\", \"check for code reuse\", \"review code quality\", \"review efficiency\", \"simplify changes\", \"clean up code\", \"refactor changes\", or \"run simplify\".
23finalize
Run the post-implementation quality assurance workflow including tests, code polishing, review, and commit. Use when the user asks to \"finalize implementation\", \"finalize changes\", \"wrap up implementation\", \"finish up\", \"ready to commit\", or \"run QA workflow\".
22self-improve
Extract lessons from the current session and route them to the appropriate knowledge layer (project AGENTS.md, auto memory, existing skills, or new skills). Use when the user asks to \"self-improve\", \"distill this session\", \"save learnings\", \"update CLAUDE.md with what we learned\", \"capture session insights\", \"remember this for next time\", \"extract lessons\", \"update skills from session\", or \"what did we learn\".
22evaluate-findings
Critically assess external feedback (code reviews, AI reviewers, PR comments) and decide which suggestions to apply using adversarial verification. Use when the user asks to \"evaluate findings\", \"assess review comments\", \"triage review feedback\", \"evaluate review output\", or \"filter false positives\".
22investigate
Systematically investigate bugs, test failures, build errors, performance issues, or unexpected behavior by cycling through characterize-isolate-hypothesize-test steps. Use when the user asks to \"investigate this bug\", \"debug this\", \"figure out why this fails\", \"find the root cause\", \"why is this broken\", \"troubleshoot this\", \"diagnose the issue\", \"what's causing this error\", \"look into this failure\", \"why is this test failing\", or \"track down this bug\".
21