# Staging Verify

> Staging environment verification gate for release merges. Triggers ONLY when: about to merge dev→main, or all milestone issues are closed and ready for release. Do NOT trigger for feature→dev merges or during development.

- Skill: `docat0209/staging-verify` (Agent Skill)
- Install (CLI): `npx skillmds@latest add docat0209/staging-verify`
- Raw SKILL.md: https://api.skillmd.com/api/skills/docat0209/staging-verify/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Docat0209 (https://skillmd.com/u/docat0209)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/docat0209/staging-verify

---


This skill is the automated pre-merge structural check for release merges (dev → main). It verifies that all changes are accounted for, environment configuration is complete, and platform settings are correct. **Functional testing (Playwright + user testing) happens AFTER merge in post-merge, not here.**

## Step 1: Identify the Delta

Run `git log main..dev --oneline` to list all changes since last release. Run `git diff main..dev --stat` to see files changed. Categorize each change: new feature (`feat:`), bug fix (`fix:`), or other. For each feat/fix commit, find the linked issue number and read its acceptance criteria.

Output a delta summary table:

| # | Type | Description | Issue # | AC Count |
|---|------|-------------|---------|----------|

## Step 2: Environment and Platform Configuration Check

Verify the environment is correctly configured before merge:

- [ ] **Environment variables**: verify ALL required env vars are documented and set for the staging/production environment (not just localhost). Check `.env.example` or deployment config for any new vars introduced in this delta.
- [ ] **OAuth/Auth config**: if the app uses OAuth (Google, GitHub, Supabase Auth, etc.), verify the redirect URLs include the production/staging domain. A common failure: redirect URLs set to `localhost` or missing from the provider's allow list.
- [ ] **Payment/webhook config**: if the app has payment integration (Stripe, Polar, etc.), verify the webhook URL and API key mode (test vs. live) match the target environment.
- [ ] **Database**: verify any new migration files exist and are committed if schema changed.
- [ ] **Third-party services**: verify all external service integrations (email, storage, CDN) have the credentials and config required for the target environment.

If ANY configuration is missing: **STOP.** Fix the configuration gap first, then re-run this check.

## Step 3: Pre-Merge Structural Verification

For each change in the delta, verify WITHOUT running the app:

- [ ] **Code completeness**: every issue's acceptance criteria can be traced to committed code changes
- [ ] **Test coverage**: every feat/fix issue has corresponding test files (unit at minimum)
- [ ] **No debug artifacts**: grep for `console.log`, `debugger`, `TODO`, `FIXME` in changed files
- [ ] **No secrets**: grep for hardcoded API keys, tokens, passwords in changed files
- [ ] **Dependencies declared**: any new npm/pip/etc. packages are in the manifest files
- [ ] **Database migrations**: if schema changed, migration files exist and are committed

This is NOT functional testing — that happens in post-merge after deployment. This is a checklist to ensure nothing was forgotten before the code hits main.

## Step 4: Verdict and Report

Generate a verification report in this format:

```markdown
## Staging Verification Report
**Date**: YYYY-MM-DD | **Staging URL**: <url> | **Dev commit**: <hash>

### Delta Summary
| # | Type | Description | Issue |
|---|------|-------------|-------|
| 1 | feat | Add CSV export | #12 |
| 2 | fix  | Sidebar collapse on mobile | #15 |

### Structural Check Results
| # | Feature | Code Complete | Tests Exist | No Debug/Secrets | Status |
|---|---------|--------------|-------------|-----------------|--------|
| 1 | CSV export | ✅ | ✅ | ✅ | ✅ PASS |
| 2 | Sidebar fix | ✅ | ✅ | ✅ | ✅ PASS |

### Verdict
✅ ALL VERIFIED — Proceeding with dev→main merge and release
```

If any structural checks fail, use this verdict block instead:

```markdown
### Verdict
❌ BLOCKED — [N] structural issues found. Fix before merging.
```

**If ALL pass:** Proceed autonomously:

1. Create PR from dev→main with the verification report as the PR body
2. Merge the PR: `gh pr merge NUMBER --merge`
3. Invoke `post-merge` (which will deploy, run Playwright verification, and create the release)

**If ANY fail:** Fix the gap (missing tests, debug artifact, undeclared dependency, etc.), commit to dev, and re-run this check. Do not merge.

## Next Steps
Report to user: "Structural check [PASS/FAIL]. Delta: [N changes]. Config: [complete/gaps]. Issues: [list]"

Suggested next steps (user decides):
- All pass → "Merge dev→main, then run post-merge"
- Failures found → "Fix gaps, then re-run"