product-verification

name

product-verification

description

Drive the running product and verify it works end-to-end. Use this skill after a deploy, before a release, or when the user says "verify", "smoke test", "does it work", "test the flow", "check staging", "end-to-end test", or "drive the product". Also use when the user wants to verify a specific user journey (signup, checkout, onboarding, upgrade). Even if the user just says "make sure it works", use this skill — unit tests pass doesn't mean the product works.

Product Verification

You verify that the product works by driving it like a real user. Unit tests check code. You check the product.

Read config.json in this skill directory for project-specific verification config (endpoints, credentials, flows to test). If it doesn't exist or says NOT_CONFIGURED, ask the user to set it up first (see Setup section below).

What you verify

Identify the critical user journeys for this project and drive each one. Common patterns — adapt to what the project actually does:

Web app / Landing page: Load the page, verify key elements render, check all navigation links, verify forms submit, check responsive breakpoints.

API: Hit each public endpoint with valid and invalid inputs. Verify status codes, response shapes, and error messages.

Discord/Slack bot: Send real commands to a test server. Verify responses, embeds, and error handling.

Billing flow: Drive signup → plan selection → checkout → verify access changes. Use test credentials.

Onboarding: Complete the first-run experience. Verify each step is reachable and functional.

For each journey, capture: what you tested, what happened, and whether it matches expectations.

How to verify

Use the tools that match the project's technology. The skill doesn't prescribe specific tools — choose based on what's available and appropriate:

• curl or requests for API endpoints
• Playwright or Puppeteer for browser-based flows
• Discord/Slack API for bot commands
• Shell scripts for CLI tools
• Direct database queries to verify state changes

If verification scripts exist in scripts/, use them. If you find yourself writing the same verification code twice, save it as a script for next time.

Output

Save results to the location the caller expects (e.g., monitoring/deploy-validation-*.md if called from a scheduled task, or sprint directory if called during a sprint).

# Product Verification — [date or sprint]

## Environment
[staging/production URL, version deployed]

## Flows tested

### [Flow name] — ✅ Pass / ❌ Fail
- **Steps**: [what was done]
- **Expected**: [what should happen]
- **Actual**: [what happened]
- **Evidence**: [response code, screenshot path, output snippet]

## Summary
X/Y flows passing
[Any critical failures that need immediate attention]

Setup

If this is the first run, create config.json in this skill directory:

{
  "project_type": "web|api|bot|cli",
  "staging_url": "https://...",
  "test_credentials": {
    "note": "Use env vars for secrets, not this file"
  },
  "critical_flows": [
    "signup → first action",
    "upgrade → verify access",
    "core command → response"
  ]
}

Ask the user which flows are critical. Don't guess — every project is different.

Gotchas

• Unit tests passing doesn't mean the product works. A deploy can break things that tests don't cover.
• Always verify on the actual deployed environment, not localhost.
• If you can't access the environment (auth, network), say so immediately — don't fake results.
• Check what the USER sees, not what the code does. An API returning 200 with wrong data is worse than a 500.
• Save verification scripts for reuse. The second run should be faster than the first.

Memory

Append results to ${CLAUDE_PLUGIN_DATA}/verification.log if available, otherwise to tasks/verification-history.log:

[YYYY-MM-DD] [env] X/Y flows passing — [clean/issues: brief description]