smoke-test

Detect end-to-end failures in a modular-dev application from a new user's perspective.

Updated May 17, 2026
One-click install
npx skills add https://github.com/Arrosam/Modular-Dev --skill smoke-test-arrosam
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: smoke-test
Source: https://github.com/Arrosam/Modular-Dev/tree/main/skills/smoke-test
Command: npx skills add https://github.com/Arrosam/Modular-Dev --skill smoke-test-arrosam

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill checks whether the assembled application actually works for a brand-new user, catching first-run problems, integration gaps, and confusing setup or usage flows that edge tests cannot see.

Core Features & Use Cases

  • Fresh-user validation: Recreates a clean clone experience in a throwaway worktree so installation, build, and startup are tested from scratch.
  • End-to-end manual testing: Drives realistic first-time scenarios, happy paths, wrong-input cases, and error-message checks from the outside.
  • Findings and fix loop: Records bugs and documentation issues, then feeds confirmed findings back into planning and development until the app passes.

Quick Start

Use this skill to smoke-test the latest assembled app as a first-time user, report what breaks, and repeat the check after fixes until the product works cleanly end to end.

Frequently Asked Questions about smoke-test

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run an end-to-end smoke test to verify a modular-dev app works for new users?

End-to-end smoke testing recreates a clean clone experience in a throwaway worktree, running the app locally to validate installation, build, and startup flows from a fresh-user perspective. It drives realistic first-time scenarios and records outcomes to catch integration gaps.

What is fresh-clone startup testing and when do I need it?

Fresh-clone startup testing checks whether the assembled application works when installed from scratch by creating a throwaway worktree. You need it after development waves or regression changes to catch first-run problems that edge tests cannot see.

How do I manually verify happy paths and wrong-input cases for regression testing?

Manual happy-path verification drives realistic first-time scenarios from outside the app, checking wrong-input cases and error messages. It records scenario outcomes in a throwaway worktree to retest changed surfaces and confirm bug fixes.

Does smoke testing a modular-dev application require reading project overviews beforehand?

Yes, smoke testing requires reading project overviews and queues before creating a throwaway worktree. This context ensures realistic first-time scenarios target the right surfaces and that confirmed bugs feed back into the fix loop properly.

What's the best way to feed confirmed bugs and documentation issues back into development?

Feeding confirmed findings back into planning and development involves recording bugs and doc-ux issues during manual testing, then repeating the smoke check after fixes until the app passes cleanly end to end without first-run problems.