# Verify A Deploy

Check in Sazabi that a change you shipped works in production before you call the task...

- Repository: https://github.com/ParadevAI/Paradev (15823 stars)
- Category: DevOps
- License: see repository
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add ParadevAI/Paradev --skill verify-a-deploy -g -a claude-code -y`
Codex: `npx skills add ParadevAI/Paradev --skill verify-a-deploy -g -a codex -y`
Cursor: `npx skills add ParadevAI/Paradev --skill verify-a-deploy -g -a cursor -y`
Gemini CLI: `npx skills add ParadevAI/Paradev --skill verify-a-deploy -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add ParadevAI/Paradev`

## Description

Check in Sazabi that a change you shipped works in production before you call the task done, compare error rates and new kinds of log lines before and after the deploy, confirm the fixed error stopped, and catch regressions early. Use after merging or deploying a fix or feature, when the user asks whether a deploy is healthy, did the fix work, or is it safe to move on.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# A task is done when production says so

Tests pass on the code you wrote. Production runs it against real traffic,
real data and real dependencies. Before you tell the user a fix shipped, check
that it changed what it was meant to change and nothing else.

## 0. How the tools work

The Sazabi MCP server lists only two tools, `search` and `execute`. Browse
Sazabi's operations with `search` and `namespace: "sazabi"` (an empty query
without a namespace lists connected connectors, not Sazabi operations). Before
calling one, repeat `search` with `namespace: "sazabi"`, the hit's full name as
the query, and `includeInputSchema: true` to load its arguments. Then run it
with `execute` as `{ name, arguments }`, the name copied from the hit (for
example `sazabi/logs.ask`).
Questions about logs go to `sazabi/logs.ask`.

## 1. Pin down the deploy

Find when the change went live: the deploy time, or the first log line that
carries the new version or commit. Every comparison below is "before that
moment" against "after it". If the change is not live yet, say so and stop.

## 2. Did the change do its job?

Ask one question for the thing the change should affect, over a window on each
side of the deploy:

- A fix: "how many times did `<the error>` occur per 10 minutes, 3 hours before
  and after <deploy time>". It should drop to zero, not just fall.
- A feature: "how many requests reached `<new endpoint or log line>` since
  <deploy time>, and how many failed". Zero traffic means it is not wired up yet.
- A performance change: ask for the latency or duration the logs record, per
  interval, on both sides.

## 3. Did it break anything else?

Ask for an overview of what is new or growing since the deploy. Look at each
new kind of error line and decide if this change could cause it. Check
`sazabi/issues.search` for issues first seen after the deploy.

## 4. Report

The rest: https://github.com/ParadevAI/Paradev/blob/HEAD/plugins/sazabi/skills/verify-a-deploy/SKILL.md