running-smoke-tests
Execute fast smoke tests validating critical functionality after deployment. Use when performing specialized testing. Trigger with phrases like "run smoke tests", "quick validation", or "test critical paths".
What this skill does
# Smoke Test Runner
## Overview
Execute fast, high-confidence smoke tests that validate critical application functionality after deployment or build. Smoke tests verify that the application starts, core user flows work, and key integrations respond -- without running the full test suite.
## Prerequisites
- Application deployed and accessible at a known URL or running locally
- HTTP client available (`curl`, `wget`, `node-fetch`, or Playwright)
- List of critical endpoints and user flows to validate
- Expected response codes and content patterns for each check
- CI/CD pipeline hook for post-deployment validation
## Instructions
1. Identify the critical paths that constitute a "working" application:
- Health check endpoint returns 200 with expected body.
- Homepage loads and contains key UI elements.
- Authentication flow succeeds with test credentials.
- Primary API endpoint returns valid data.
- Database connection is active and responding.
2. Create a smoke test configuration listing each check:
- URL or command to execute.
- Expected HTTP status code (200, 301, etc.).
- Response body pattern to match (substring or regex).
- Maximum acceptable response time (e.g., 3 seconds).
3. Write the smoke test suite as a lightweight script or test file:
- Use `curl` for HTTP checks or Playwright for browser-based checks.
- Run checks sequentially for simplicity (parallel for speed if independent).
- Fail fast on the first critical failure.
- Log each check result with pass/fail, response time, and status code.
4. Implement timeout guards:
- Set a global timeout of 60 seconds for the entire smoke suite.
- Set per-check timeouts of 5-10 seconds.
- Treat timeouts as failures, not retries.
5. Add deployment-gate integration:
- On success: proceed with deployment promotion or traffic shifting.
- On failure: trigger rollback and send alert notification.
- Report results to CI/CD dashboard and Slack/Teams webhook.
6. Store smoke test results as CI artifacts for audit trail.
7. Schedule periodic smoke runs (every 5 minutes in production) as synthetic monitoring.
## Output
- Smoke test script (`scripts/smoke-test.sh` or `tests/smoke.test.ts`)
- Pass/fail result for each critical check with response times
- Deployment gate verdict (PASS or FAIL with reason)
- CI artifact with timestamped smoke test log
- Alert payload for failed checks (Slack webhook, PagerDuty, etc.)
## Error Handling
| Error | Cause | Solution |
|-------|-------|---------|
| Connection refused | Application not yet ready after deployment | Add a startup wait with exponential backoff (max 30 seconds) before running smoke tests |
| 503 Service Unavailable | Application is starting or behind a load balancer draining | Retry with 2-second delay up to 3 times; check load balancer health check status |
| Unexpected redirect (301/302) | URL changed or SSL redirect not accounted for | Follow redirects with `curl -L`; update expected URLs in smoke config |
| Content mismatch | Page content changed but smoke test pattern is too specific | Use broad patterns (check for `<title>` or key element IDs, not exact text) |
| Timeout on database check | Database migration running or connection pool exhausted | Increase timeout for database checks; verify migration completed before smoke tests |
## Examples
**Shell-based smoke test script:**
```bash
#!/bin/bash
set -e
BASE_URL="${1:-http://localhost:3000}" # 3000: 3 seconds in ms
PASS=0; FAIL=0
check() {
local name="$1" url="$2" expected="$3"
status=$(curl -s -o /dev/null -w '%{http_code}' --max-time 5 "$url")
if [ "$status" = "$expected" ]; then
echo "PASS: $name (HTTP $status)"
((PASS++))
else
echo "FAIL: $name (expected $expected, got $status)"
((FAIL++))
fi
}
check "Health check" "$BASE_URL/health" "200" # HTTP 200 OK
check "Homepage" "$BASE_URL/" "200" # HTTP 200 OK
check "API status" "$BASE_URL/api/status" "200" # HTTP 200 OK
check "Login page" "$BASE_URL/login" "200" # HTTP 200 OK
echo "Results: $PASS passed, $FAIL failed"
[ "$FAIL" -eq 0 ] || exit 1
```
**Playwright smoke test:**
```typescript
import { test, expect } from '@playwright/test';
test('homepage loads with navigation', async ({ page }) => {
await page.goto('/', { timeout: 10000 }); # 10000: 10 seconds in ms
await expect(page.locator('nav')).toBeVisible();
await expect(page).toHaveTitle(/My App/);
});
test('API health endpoint responds', async ({ request }) => {
const response = await request.get('/api/health');
expect(response.ok()).toBeTruthy();
expect(await response.json()).toHaveProperty('status', 'ok');
});
```
## Resources
- Smoke testing methodology: https://martinfowler.com/bliki/SmokeTest.html
- Playwright API testing: https://playwright.dev/docs/api-testing
- curl documentation: https://curl.se/docs/manpage.html
- GitHub Actions deployment gates: https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment
Related in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.