code/smoke-test/SKILL.md
Traces and verifies that something works end-to-end in any environment. Builds a check plan from natural language input, confirms it, then runs each check reporting pass/fail. Use when validating deployments, pipelines, features, or migrations.
npx skillsauth add mostafa-drz/claude-skills smoke-testInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Trace a resource, event, or feature through the system and verify it works end-to-end.
Read ~/.claude/skills/smoke-test/preferences.md using the Read tool. If not found, no preferences are set.
On startup, use Bash to detect: CLAUDE.md presence, project stack files (ls package.json Cargo.toml pyproject.toml go.mod requirements.txt), and current git branch. Skip any that fail.
Check $ARGUMENTS:
help → display help then stopconfig → interactive setup then stopreset → delete ~/.claude/skills/smoke-test/preferences.md, confirm, stopSmoke Test — Trace and verify something works end-to-end
Usage:
/smoke-test <natural language> Build and run a trace plan
/smoke-test config Set environment and verbosity defaults
/smoke-test reset Clear preferences
/smoke-test help This help
Examples:
/smoke-test uploaded a file to workspace 30 in prod, check the pipeline
/smoke-test verify login flow on staging
/smoke-test did my migration run correctly in production?
/smoke-test check webhook fires after order creation in dev
How it works:
1. Reads project context (CLAUDE.md, repo structure, APIs)
2. Builds a trace plan — ordered checks
3. Confirms the plan with you
4. Runs each check, reporting pass/fail
5. Summarizes with diagnosis
Current preferences:
(shown above under Preferences)
Use AskUserQuestion:
Q1 — "Default environment?" (Production, Staging/Dev, Local, Ask each time (default)) Q2 — "Trace output verbosity?" (Concise, Detailed, Verbose on failure (default))
Save to ~/.claude/skills/smoke-test/preferences.md.
If no preferences file exists, show:
"First time using /smoke-test? Run /smoke-test config to set default environment and verbosity, or continue — I'll auto-detect."
Then proceed normally.
Read project context silently:
ls top-level)From $ARGUMENTS, extract:
If critical info is missing, ask via AskUserQuestion.
Build an ordered list of checks. Each check:
See reference/check-patterns.md for heuristics on what to check.
Smoke test plan for: [what we're verifying]
Environment: [env]
Checks:
1. [Check name] — [how, briefly]
2. [Check name] — [how, briefly]
3. [Check name] — [how, briefly]
Estimated: [N] API calls
Use AskUserQuestion: "Run this trace plan?" (Run all, Select specific, Add a check, Skip)
Run each check sequentially (respecting dependencies):
[PASS] Check name
Key details: value
[FAIL] Check name
Expected: X
Got: Y
[SKIP] Check name
Depends on failed check
On failure: show expected vs actual, suggest likely cause, ask to continue or stop.
Output patterns by verbosity preference:
Smoke Test Results: [what was verified]
Environment: [env]
[PASS] X/N checks passed
[FAIL] Y/N checks failed
[SKIP] Z/N checks skipped
Failed:
- [Check]: [one-line reason]
Diagnosis:
[Root cause or pattern if identifiable]
Suggested next steps:
- [Action per failure]
development
--- name: triage-board description: >- Generates a structured triage artifact from the current conversation's findings — a self-contained Desktop folder with a JSON Schema, schema-conformant report.json, prose markdown, and a single-file HTML viewer. Viewer ships with MD / CSV / JSON download buttons in the header and a per-finding "Copy as Markdown" action that produces a GitHub/Linear/Notion-ready ticket block. Stateless — triage state lives in the user's ticket system, not in the
development
Runs a beginner-mind end-to-end UI audit of any running app — local dev server, staging, production, or a specific URL. Drives Chrome through every interactive element on the target surface, collects structured findings (severity, category, where, symptom, impact, repro, triage), and hands the result off to `/triage-board` which produces the Desktop folder (schema + JSON + Markdown + single-file HTML viewer with MD/CSV/JSON exports and a per-finding Copy as Markdown button). Use when you want fresh-eyes verification of a feature, page, modal, flow, branch, or whole app — before shipping, before review, before a demo, or any time the UI deserves a careful poke.
development
Reviews the user's past Claude Code conversations from a wellbeing perspective — sentiment, tone, emotional arc, recurring patterns — and generates a supportive, science-grounded report in both Markdown and HTML. Default lookback is 48 hours across all projects. Uses recognised emotion frameworks (Plutchik, Ekman, Russell's circumplex, Pennebaker linguistic markers) and cites the science behind every observation. Learns the user's baseline tone over time so future reports flag genuine shifts, not noise. Use when the user asks for an emotional/wellbeing recap, mood check, sentiment review, or wants to understand their own ups and downs across recent work sessions.
development
--- name: workflow-advisor description: >- Analyzes recent Claude Code conversations and local Claude state (skills, settings, memory files, CLAUDE.md), researches the latest Claude Code features and best practices online, and suggests one workflow improvement at a time with reasoning and a concrete action item. Can save accepted suggestions to memory for tracking. Use when you want to discover underused Claude Code features, improve your development workflow, stay current with the lat