smoke
Skill5 starsChanged 4 months agoMITView on GitHub
Runs production smoke tests to verify the deployed application works correctly in the live environment. This skill should be used when the user asks to "run production smoke tests", "verify the production deployment", "smoke test the live app", "check if production is working", "run post-deployment verification", "run stage 7V", or "verify the deployed application", or when the transmute-pipeline agent reaches Stage 7V of the pipeline.
- Reads credentials
5 other projects use a version of this.
Adopted by
Most recently taken up by
- nightly-labs/openbottheir own version, first seen Nov 8, 2026
- thalissonbarbosas/hangartheir own version, first seen Oct 9, 2026
- assaio/assaiotheir own version, first seen Sep 29, 2026
- pgnzbl-ux/crucibletheir own version, first seen Aug 27, 2026
- lfrodrigues/packt-claude-code-course-auththeir own version, first seen Jul 15, 2026
Other versions5 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 5
- nightly-labs/openbot★ 6.3ksame name
- assaio/assaio★ 63same name
- lfrodrigues/packt-claude-code-course-auth★ 9same name
- pgnzbl-ux/crucible★ 4same name
- thalissonbarbosas/hangar★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository24 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- templates/CLAUDE.mdCLAUDE.md
- audit-a11ySkill
- audit-completenessSkill
- audit-securitySkill
- brdSkill
- docsSkill
- feedbackSkill
- hardenSkill
- implementSkill
- maintainSkill
- optimizeSkill
- polishSkill
- prdSkill
- prelaunchSkill
- redesignSkill
- refactorSkill
- remediateSkill
- scaffoldSkill
- seed-dataSkill
- tech-stackSkill
- user-guideSkill
- validate-specsSkill
- verifySkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
27 rules. 0 are common, 16 are distinctive, and 11 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
16
Distinctive
This author's own choices. Worth a look.
11
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 17
Read the detailed guide at ${CLAUDE_SKILL_DIR}/references/smoke-detailed-guide.md for the full verification checklist, report template, …
- Very specific: line 21
Verify the production URL is accessible and responding.
- Very specific: line 22
Check ./plancasting/_launch/readiness-report.md exists.
- Very specific: line 23
If 6R was run, verify ./plancasting/_audits/runtime-remediation/report.md shows PASS or CONDITIONAL PASS.
- Very specific: line 24
Verify ./plancasting/_audits/visual-verification/report.md or ./plancasting/_audits/visual-polish/report.md exists.
- Very specific: line 25
Verify scenario generation file exists: ./plancasting/transmute-framework/feature_scenario_generation.md.
- Very specific: line 31
Read CLAUDE.md, plancasting/tech-stack.md, and check plancasting/tech-stack.md for the Session Language setting.
- Very specific: line 51
Before any verification, generate a targeted test plan.
- Distinctive: line 59
If no 6V matrix exists: Read the scenario generation guide and PRD files.
- Very specific: line 65
Infrastructure Checks: Verify DNS resolution, SSL certificate validity (not expired, not self-signed), HTTPS redirect (HTTP -> HTTPS), and …
- Distinctive: line 97
PASS: All critical flows work, all pages load, no console errors, all external APIs respond 2xx.
- Distinctive: line 98
CONDITIONAL PASS: All P0 critical flows pass, all pages load, but minor issues exist in P1/P2 features (e.g., non-critical integration …
- Distinctive: line 101
Flaky = FAIL: If a scenario fails once but passes on retry, treat it as FAIL.
- Distinctive: line 116
always use the PRODUCTION URL -- never test against localhost.
- Distinctive: line 117
never modify production data beyond test accounts.
- Distinctive: line 118
never test payment flows with real payment methods.
- Very specific: line 119
Use identifiable test accounts (smoke-test-*@domain).
- Distinctive: line 120
If ANY critical flow fails, follow rollback guidance.
- Distinctive: line 121
Keep this stage FAST -- 25-45 minutes max.
- Distinctive: line 122
always compare against Stage 6V results for deployment-specific regressions.
- Distinctive: line 124
always clean up test accounts after verification.
- Distinctive: line 125
always verify test user login works BEFORE authenticated page checks.
- Very specific: line 126
always test public utility routes (/sitemap.xml, /robots.txt, /api/health) WITHOUT authentication.
- Distinctive: line 127
always verify 6R fixes BEFORE detailed feature/navigation checks if 6R report exists.
- Distinctive: line 128
always test navigation at BOTH desktop and mobile viewports.
- Distinctive: line 129
always check deployed commit hash against 6R remediation commit hash if 6R report exists.
- Distinctive: line 131
never modify application code, production configuration, or database records during this stage (except test account creation/cleanup).
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Production Smoke Verification — Stage 7V
Read the detailed guide at ${CLAUDE_SKILL_DIR}/references/smoke-detailed-guide.md for the full verification checklist, report template, known failure patterns, and rollback guidance. Read ${CLAUDE_SKILL_DIR}/references/feature-scenario-generation.md for the scenario generation algorithm.
Prerequisites
- Verify the production URL is accessible and responding. Check with
curl -sI <production-url> | head -1(expect HTTP 200 or 301/302). If unreachable, STOP and verify deployment status. - Check
./plancasting/_launch/readiness-report.mdexists. If it shows FAIL, stop and report the blocker. If READY or CONDITIONAL PASS with documented minor issues, proceed. If it does not exist, proceed but note in the report: "Stage 6H pre-launch verification was not completed." - If 6R was run, verify
./plancasting/_audits/runtime-remediation/report.mdshows PASS or CONDITIONAL PASS. If FAIL, STOP — 6R must pass before Stage 7. - Verify
./plancasting/_audits/visual-verification/report.mdor./plancasting/_audits/visual-polish/report.mdexists. Warn if neither is found. - Verify scenario generation file exists:
./plancasting/transmute-framework/feature_scenario_generation.md. If missing, copy from the Transmute Framework Template directory. See CLAUDE.md § "Pre-6V Setup" for copy instructions. - Create output directories:
mkdir -p ./plancasting/_audits/production-smoke mkdir -p ./screenshots/production - Read
CLAUDE.md,plancasting/tech-stack.md, and checkplancasting/tech-stack.mdfor theSession Languagesetting. Generate all reports in the specified language.
Inputs
- Production URL: The live application URL
- Scenario Generation Guide:
${CLAUDE_SKILL_DIR}/references/feature-scenario-generation.md(if not available, use PRD files directly) - 6V Scenario Matrix (if exists):
./plancasting/_audits/visual-verification/feature-scenario-matrix.md - 6V Report:
./plancasting/_audits/visual-verification/report.md - 6R Report (if exists):
./plancasting/_audits/runtime-remediation/report.md - 6P/6P-R Report (if exists):
./plancasting/_audits/visual-polish/report.md - PRD files:
./plancasting/prd/02-feature-map-and-prioritization.md,04-epics-and-user-stories.md,06-user-flows.md,07-information-architecture.md,08-screen-specifications.md - Tech Stack:
./plancasting/tech-stack.md - E2E Config:
./playwright.config.ts,./e2e/constants.ts
Execution Flow
This is a single-agent sequential check. Target completion: 25-45 minutes (3-5 min scenario generation + 15-25 min core checks + 5-8 min for 6R/6P/navigation verification + 2-5 min performance/integrations). If the application exceeds 50+ pages or 10+ integrations, consider running a scoped Stage 6V (critical mode) against the production URL instead.
Step 0: Generate Smoke Scenario Matrix
Before any verification, generate a targeted test plan. Save to ./plancasting/_audits/production-smoke/smoke-scenario-matrix.md.
Scope: SMOKE — P0+P1 features only, max 15 scenarios.
Generation mode: SMOKE — P0/P1 features only, happy path Feature Scenarios + one authenticated/unauthenticated Auth Context check per route. No Entity State, Role Permission, or Negative Scenarios. Target: 15 scenarios max.
If 6V scenario matrix exists: Filter to P0 + P1 feature scenarios only, happy path, no negative variants. Filter auth contexts to unauthenticated + one authenticated role. Skip entity state and role permission scenarios. Target ~10-15 scenarios.
If no 6V matrix exists: Read the scenario generation guide and PRD files. Generate feature scenarios for P0 + P1 features only, one scenario per flow (happy path). Target ~10-15 scenarios.
If generation fails: Fall back to hardcoded minimum flows (authentication, core feature, settings).
Steps 1-3: Infrastructure and Baseline
- Infrastructure Checks: Verify DNS resolution, SSL certificate validity (not expired, not self-signed), HTTPS redirect (HTTP -> HTTPS), and security headers (CSP, X-Frame-Options, etc.). Use CLI tools (
nslookup,openssl,curl) if available; fall back to Playwright browser tools. - Environment Variable Spot-Check: Check for missing or misconfigured env vars. Verify BaaS URLs, auth provider URLs, naming consistency across all
process.env.*reads, and backend deployment target. Cross-check third-party service tier limits. Early AI model validation: Check all AI model IDs used in code against the provider's documentation; send a 1-token test request for each model to verify they exist and respond. - Reuse 6V Playwright Tests (if
e2e/verification/exists): Run them against production URL withBASE_URL=https://[domain]. Flaky = FAIL: If any test requires a retry to pass, treat it as FAIL for gate purposes — production flakiness is unacceptable.
Steps 4-8: Core Verification
- Critical Page Load Verification: Test all public pages in a FRESH browser context (no cookies/localStorage). Verify HTTP 200, correct body content (not login page served with 200), and no auth console errors. Test protected route redirect behavior. Test authenticated pages after logging in as a test user. For each page: verify HTTP 200, no console errors, content renders, CSS loads, JS executes, data loads, take screenshot.
- 6R Fix Verification (if 6R report exists): Re-test each auto-fixed issue on production. Verify deployed commit hash matches 6R report commit hash. If any fix is missing, flag as CRITICAL and check deployed commit hash.
- 6P/6P-R Visual Polish Verification (if visual polish report exists): Spot-check top 3 most impactful visual changes survived production build. 6P-R branch merge check: If 6P-R was used (check for
design-plan.md), verifyredesign/frontend-elevationbranch was merged to main before deployment. Flag missing changes as MEDIUM severity. - Navigation Smoke Test (~5 min max): Test desktop sidebar, footer, mobile nav, sub-navigation tabs. Check CSS styling intact at both viewports. Flag invisible/unstyled links as CRITICAL (likely Tailwind CSS purging).
- Critical User Flow Verification: Execute P0 scenarios from smoke matrix. Follow dependency graph. If P0 fails, mark dependents as BLOCKED. Fall back to minimum flows if no matrix exists.
Steps 9-11: Visual, Performance, Integrations
- AI Vision Spot-Check: Screenshot 5 most important pages. Compare against 6V screenshots for visual differences.
- Performance Spot-Check: Measure TTFB and LCP for landing page and dashboard. Flag if >2x slower than dev.
- Third-Party Integration Verification: Verify auth, database, payments, email, analytics, error monitoring, webhooks, real-time connections. Verify AI model IDs first (grep codebase, send minimal test request). Run external API health checks with minimal requests (cost warning: real API calls against production keys). Verify OAuth integration health for each connected service (check redirect_uri matches, client IDs, provider app registration).
Output
Generate ./plancasting/_audits/production-smoke/report.md following the report template in the detailed guide. The report includes: summary, infrastructure results, page load results, public route access, protected route redirect, 6R/6P/6P-R verification, navigation smoke test, scenario results, visual comparison, performance, third-party integrations, gate decision, next steps, issues found, and screenshot references.
Gate Decision
- PASS: All critical flows work, all pages load, no console errors, all external APIs respond 2xx. Proceed to Stage 7D (User Guide Generation).
- CONDITIONAL PASS: All P0 critical flows pass, all pages load, but minor issues exist in P1/P2 features (e.g., non-critical integration timeout, minor visual discrepancy from 6V baseline). Document issues for post-launch fix. Stage 7D and Stage 8 can proceed.
- FAIL: Any critical flow broken, pages don't load, critical navigation failure (invisible/unstyled links), external API health check fails, or 6R fixes missing from deployment. Immediate action required per rollback guidance.
Flaky = FAIL: If a scenario fails once but passes on retry, treat it as FAIL. Production flakiness is unacceptable. Non-critical visual issues do not trigger FAIL; document them for Stage 8.
FAIL decision tree: (1) If issue is localized (1-2 files, <100 LOC fix): hotfix in code, re-deploy, re-run 7V. (2) If issue affects multiple systems or requires >2 hours to fix: execute rollback (git revert HEAD), verify reverted deploy is stable, investigate offline.
Failure Escalation Protocol
| Failure Type | Action |
| Auth completely broken (login 500s) | Rollback deployment immediately |
| Core data query empty (DB inaccessible) | Check backend deployment status; rollback if needed |
| SSR hydration errors on landing page | Check Tailwind CSS purging; hotfix if CSS issue |
| 3rd-party integration failure | Do not rollback; escalate to operator to verify API keys |
Critical Rules
- always use the PRODUCTION URL -- never test against localhost.
- never modify production data beyond test accounts.
- never test payment flows with real payment methods.
- Use identifiable test accounts (
smoke-test-*@domain). - If ANY critical flow fails, follow rollback guidance. Do not mark as "known issue for later."
- Keep this stage FAST -- 25-45 minutes max.
- always compare against Stage 6V results for deployment-specific regressions. 7a. Flaky scenarios = FAIL in production. Do not mark as passing if it required a retry.
- always clean up test accounts after verification.
- always verify test user login works BEFORE authenticated page checks.
- always test public utility routes (
/sitemap.xml,/robots.txt,/api/health) WITHOUT authentication. - always verify 6R fixes BEFORE detailed feature/navigation checks if 6R report exists.
- always test navigation at BOTH desktop and mobile viewports.
- always check deployed commit hash against 6R remediation commit hash if 6R report exists.
- Spot-check 6P/6P-R visual polish changes if visual polish report exists.
- never modify application code, production configuration, or database records during this stage (except test account creation/cleanup).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

