원클릭으로 Manus에서 모든 스킬 실행

deploy-verify

스타0

포크0

업데이트2026년 7월 25일 03:00

Staging/prod deploy verification — proves the build actually works in the live environment, not that a dashboard says "Ready". Runs the deployed-code ladder (curl the new route, grep served HTML, digest-pin — merged ≠ deployable ≠ deployed), re-runs the Test Contract's [REAL]-tagged cases against the live env under Tier-2 rules, walks the release checklist (rollback, monitoring, feature flags, migration safety, credential hygiene), and emits READY / NOT-READY with per-item evidence. Invoked by /review-it when the target is "staging"/"prod"/a release, or standalone when the user says "verify the deploy", "is it actually live", "pre-release check", "can we ship this".

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

DevOtts

DevOtts/review-it

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

/deploy-verify — staging/prod verification

You prove a build works where it will actually run. Status proxies — MERGED, "Ready", a green layer-cached build — are never deploy evidence (gate R8). The failure class this mode kills: a "merged + Ready" deploy whose new route 404'd in prod.

Gates applied here: R8 deploy-truth, R4 first-look, R9 environment-identity, R3 read-stability — full specs in references/gate-catalog.md; tiers/statuses in references/vocabularies.md; report rows per references/report-format.md.

Step 1 — Deployed-code ladder FIRST (R8; FR4.1)

Before any functional check, prove the new code is actually serving in the target env. Climb until one rung gives positive proof:

curl the new route/endpoint — a route that exists only in the new code returning 200/401 (vs 404) proves the new code serves. (401 is proof too — the route exists behind auth.)
grep the served HTML/JS for a marker unique to the change (new string, build id, component id).
digest-pin — compare the running image/bundle digest against the built artifact's digest.

Preflight identity applies (R9): prove which env/URL/port you are hitting before trusting any rung. No rung passing ⇒ the deploy is NOT live; report FAIL on the ladder and stop functional verification — everything after would test the old code.

Step 2 — Re-run [REAL] contract cases against the live env (FR4.2)

Pull the consumer's Test Contract (or derived contract) and re-run its [REAL]-tagged rows against staging/prod — this is the "test it working there" leg. Tier-2 rules (vocabularies §2) bind:

These runs never block a PR — they inform the release verdict.
Unreachable live target ⇒ honest IMPLEMENTED-NOT-VERIFIED with named blocker (temporary|structural) — never a mock stand-in ([REAL] is never VERIFIED on a mock).
Execution routes by row shape: UI rows → build-it:full-qa, API/state rows → direct calls with ledger entries, fix loops → build-it:iterate (CB-3).
Human-reserved live actions (prod credential flips, first live write) are BLOCK stop-gates carrying the R4 first-look ask — "ping me before acting," or poll to observe first state; the human is never the un-instrumented first tester.

Step 3 — Release checklist (FR4.3)

Walk each item to a PASS/INV row with evidence:

Rollback plan — named, executable (previous image/release tag reachable), not "revert the PR".
Monitoring/alerting — the new surface is covered (dashboard, alert rule, log query named).
Feature-flag state — flags gating the change are in the intended state in THIS env; quote the flag read.
Migration safety — destructive migrations follow the safety ladder (backup → grep → soft-delete → soak → hard-delete → verify, CB-8); irreversible steps are human-gated.
Credential hygiene — no new secrets in the bundle/env dump; credential operations human-gated, rotations verified by live call (R5/CB-6).

Step 4 — Verdict (FR4.4)

Emit READY / NOT-READY assembled ONLY from the per-item rows: any ladder FAIL ⇒ NOT-READY; Tier-2 INVs force an honest row and a human decision, not silent green. Report per references/report-format.md, R10 debrief included.

What NOT to do

Do not accept MERGED / "Ready" / green CI / cached builds as deploy evidence (R8).
Do not run functional checks before the ladder proves the new code serves — you'd verify the old build.
Do not mock an unreachable staging/prod target — INV with named blocker (Tier-2).
Do not perform human-reserved prod actions autonomously (R4; BLOCK stop-gate).
Do not inline QA/fix-loop/browser logic — route to build-it:full-qa / build-it:iterate / build-it:chrome-cdp-control by name (CB-3).

Authored by DevOtts.

이 저장소의 다른 Skills

같은 저장소

review-it

DevOtts/review-it

The QA front door of the DevOtts lifecycle family — plan-it plans, build-it builds, /review-it verifies. PRIMARY mission: run the unit tests, e2e tests and test-cases generated at plan phase to prove the build obeys the plan — the independent verification leg of the plan→build→review triangle. Also verifies third-party side-effects (the Airtable class), staging/prod deploys (deployed-code ladder + [REAL] re-runs), and runs a severity-tiered PR review. Routes execution to full-qa, iterate, chrome-cdp-control, make-eval and parallel-lifecycle — never re-implements them — and enforces an 11-rule gate catalog that makes false-VERIFIED claims un-shippable. Invoked with no Test Contract it never refuses and never self-grades — it runs the no-contract ladder and tags every verdict AUTHORED or DERIVED. Use when the user says "/review-it", "review it", "verify the build", "run the test contract", "QA this feature", "verify this deploy", "review this PR", or when build-it reaches its QA phase.

Third-party side-effect verification — the Airtable failure class, first-class. Verifies that writes to external systems (Airtable, Slack, Shopify, CRMs, payment providers) actually landed, by reading the record back from the target system's OWN surfaces — API GET for field values AND the UI render for display semantics — with read-back stability (2–3 reads) and real-target coverage. Invoked by /review-it when a DoD includes third-party writes, or standalone when the user says "verify the write landed", "check the Airtable/Slack/Shopify record", "did the integration actually save it". A write verified only by sender-side success is not verified.

2026-07-250

pr-review

DevOtts/review-it

SECONDARY review-it mode — the PR-review PROCESS wrapper. Produces severity-tiered (BLOCKER/MAJOR/MINOR/NIT), evidence-cited (file:line) findings with a blocking-vs-advisory split, loading the consumer project's checklist from .claude/review-config.md (works with zero config via a generic checklist). It does not duplicate /code-review — it may invoke code-review-style passes as executors and wraps them in process: scope, checklist, severity, evidence, verdict. Invoked by /review-it when the target is a PR ref/branch/diff, or standalone when the user says "review this PR", "review the diff", "pre-merge review".

2026-07-150

name	deploy-verify
description	Staging/prod deploy verification — proves the build actually works in the live environment, not that a dashboard says "Ready". Runs the deployed-code ladder (curl the new route, grep served HTML, digest-pin — merged ≠ deployable ≠ deployed), re-runs the Test Contract's [REAL]-tagged cases against the live env under Tier-2 rules, walks the release checklist (rollback, monitoring, feature flags, migration safety, credential hygiene), and emits READY / NOT-READY with per-item evidence. Invoked by /review-it when the target is "staging"/"prod"/a release, or standalone when the user says "verify the deploy", "is it actually live", "pre-release check", "can we ship this".
version	1.0.0
license	MIT
author	DevOtts
author_url	https://github.com/DevOtts
homepage	https://github.com/DevOtts/review-it
repository	https://github.com/DevOtts/review-it
keywords	["deploy","staging","prod","release","deployed-code-ladder","readiness","qa"]

/deploy-verify — staging/prod verification

Step 1 — Deployed-code ladder FIRST (R8; FR4.1)

Before any functional check, prove the new code is actually serving in the target env. Climb until one rung gives positive proof:

curl the new route/endpoint — a route that exists only in the new code returning 200/401 (vs 404) proves the new code serves. (401 is proof too — the route exists behind auth.)
grep the served HTML/JS for a marker unique to the change (new string, build id, component id).
digest-pin — compare the running image/bundle digest against the built artifact's digest.

Step 2 — Re-run [REAL] contract cases against the live env (FR4.2)

Pull the consumer's Test Contract (or derived contract) and re-run its [REAL]-tagged rows against staging/prod — this is the "test it working there" leg. Tier-2 rules (vocabularies §2) bind:

These runs never block a PR — they inform the release verdict.
Unreachable live target ⇒ honest IMPLEMENTED-NOT-VERIFIED with named blocker (temporary|structural) — never a mock stand-in ([REAL] is never VERIFIED on a mock).
Execution routes by row shape: UI rows → build-it:full-qa, API/state rows → direct calls with ledger entries, fix loops → build-it:iterate (CB-3).
Human-reserved live actions (prod credential flips, first live write) are BLOCK stop-gates carrying the R4 first-look ask — "ping me before acting," or poll to observe first state; the human is never the un-instrumented first tester.

Step 3 — Release checklist (FR4.3)

Walk each item to a PASS/INV row with evidence:

Rollback plan — named, executable (previous image/release tag reachable), not "revert the PR".
Monitoring/alerting — the new surface is covered (dashboard, alert rule, log query named).
Feature-flag state — flags gating the change are in the intended state in THIS env; quote the flag read.
Migration safety — destructive migrations follow the safety ladder (backup → grep → soft-delete → soak → hard-delete → verify, CB-8); irreversible steps are human-gated.
Credential hygiene — no new secrets in the bundle/env dump; credential operations human-gated, rotations verified by live call (R5/CB-6).

Step 4 — Verdict (FR4.4)

What NOT to do

Do not accept MERGED / "Ready" / green CI / cached builds as deploy evidence (R8).
Do not run functional checks before the ladder proves the new code serves — you'd verify the old build.
Do not mock an unreachable staging/prod target — INV with named blocker (Tier-2).
Do not perform human-reserved prod actions autonomously (R4; BLOCK stop-gate).
Do not inline QA/fix-loop/browser logic — route to build-it:full-qa / build-it:iterate / build-it:chrome-cdp-control by name (CB-3).

Authored by DevOtts.