Agent skill

Verify Deployment PR

by OriginProtocol in OriginProtocol/origin-dollar

Verifies a POST-EXECUTION mainnet (or other network) smart-contract deployment PR for this repo: confirms every deployed contract is listed in the PR description, that the on-chain verified source…

MITAuto-check: notesBackend & APIs

Install Verify Deployment PR

skills CLI
$ npx skills add OriginProtocol/origin-dollar --skill verify-deployment-pr -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install OriginProtocol/origin-dollar verify-deployment-pr --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/OriginProtocol/origin-dollar.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/verify-deployment-pr .claude/skills/verify-deployment-pr && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
verify-deployment-pr
GitHub stars
153
Token cost
~2.6k tokens
SKILL.md length
1,100 words
Files
1
Skills in repo
7
Repo updated
First seen
Licence
MIT

At a glance

Verifies a POST-EXECUTION mainnet (or other network) smart-contract deployment PR for this repo: confirms every deployed contract is listed in the PR description, that the on-chain verified source…

  • Works in 4 steps: Prerequisites (fail fast) → Gather PR context → Run the checks → …
  • Asked to review
  • SKILL.md covers Step 0 — Prerequisites (fail…, Step 1 — Gather PR context, Step 2 — Run the checks and Step 3 — Synthesize, plus 2 more sections
  • Calls git, gh and npm; needs ETHERSCAN_API_KEY

What it does

Verify Deployment PR is an agent skill from OriginProtocol/origin-dollar. Verifies a POST-EXECUTION mainnet (or other network) smart-contract deployment PR for this repo: confirms every deployed contract is listed in the PR description, that the on-chain verified source (and its dependencies) matches the codebase via sol2uml diff, that constructor args and the initialize tx match the Foundry script, and that the on-chain governance proposal matches the script's actions. Use when asked to review, verify, audit, or sign off on an executed deployment PR. Invoke explicitly with…

Its SKILL.md is about 2.6k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Backend & APIs, covering Smart contracts, Deployment and Pull requests. It works with Git. The repository describes itself as: OUSD and OETH are stablecoins that passively accrue yield while you are holding it. The licence is MIT.

When your agent uses it

  • Asked to review
  • Sign off on an executed deployment PR

Example prompts

  • “Use the verify-deployment-pr skill to verify a POST-EXECUTION mainnet (or other network) smart-contract deployment PR for this repo: confirms every…”
  • “/verify-deployment-pr”

Requirements

  • Node.js
  • A credential in ETHERSCAN_API_KEY
  • Pre-approved tools (allowed-tools): Bash, Read, Grep, Glob, Task

Workflow steps

4 steps, taken from the step headings in SKILL.md.

  1. Prerequisites (fail fast)
  2. Gather PR context
  3. Run the checks
  4. Synthesize

What it can do on your machine

Read from SKILL.md and the folder at commit 1be34f7. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Bash
    • Read
    • Grep
    • Glob
    • Task

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git
    • gh
    • npm
    • pnpm

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, gh, npm and pnpm, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • ETHERSCAN_API_KEY

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Verify Deployment PR loads about 2.6k tokens when it runs. Until then it costs about 140 tokens; SKILL.md has 1,100 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~140
When it runs · the whole SKILL.md, loaded when a task matches
~2.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NoteMentions a .env fileSKILL.md:25
    2. Require `contracts/.env` with `PROVIDER_URL` and `ETHERSCAN_API_KEY`:
  • NoteMentions a .env fileSKILL.md:26
    -oE '^(PROVIDER_URL|ETHERSCAN_API_KEY)=' .env`. Source it for shell use:
  • NoteMentions a .env fileSKILL.md:27
    `set -a; . ./.env; set +a` (so `$ETHERSCAN_API_KEY` is available to `sol2uml`).
  • NoteMentions a .env fileSKILL.md:158
    diff`, run from `contracts/` and source `.env` first so `$ETHERSCAN_API_KEY`
  • NotePre-approves every shell command (allowed-tools: Bash)SKILL.md
    allowed-tools: Bash, Read, Grep, Glob, Task

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from OriginProtocol/origin-dollar at commit 1be34f7, republished under its MIT licence (© OriginProtocol). 1,100 words, ~2,573 tokens.

Download SKILL.mdSave it as .claude/skills/verify-deployment-pr/SKILL.md (or your agent's skills folder).
name
verify-deployment-pr
description
Verifies a POST-EXECUTION mainnet (or other network) smart-contract deployment PR for this repo: confirms every deployed contract is listed in the PR description, that the on-chain verified source (and its dependencies) matches the codebase via `sol2uml diff`, that constructor args and the initialize tx match the Foundry script, and that the on-chain governance proposal matches the script's actions. Use when asked to review, verify, audit, or sign off on an executed deployment PR. Invoke explicitly with /verify-deployment-pr <PR#>.
allowed-tools
Bash, Read, Grep, Glob, Task
argument-hint
<PR#>
disable-model-invocation
false

Verify Deployment PR

READ-ONLY audit of an already-executed deployment PR. Never broadcast a transaction, never edit files, never re-run the live deployment. All on-chain data comes from the block explorer (via sol2uml/Etherscan) or a read-only RPC.

Step 0 — Prerequisites (fail fast)

  1. All commands run from contracts/: cd contracts.
  2. Require contracts/.env with PROVIDER_URL and ETHERSCAN_API_KEY: grep -oE '^(PROVIDER_URL|ETHERSCAN_API_KEY)=' .env. Source it for shell use: set -a; . ./.env; set +a (so $ETHERSCAN_API_KEY is available to sol2uml).
    • Missing ETHERSCAN_API_KEY → checks 2/3/4 can't run → STOP and report the blocker.
  3. Require gh authenticated (gh auth status). If absent, ask the user to paste the PR body + deployed-address list rather than failing.
  4. Require sol2uml on PATH (command -v sol2uml). If absent: npm i -g sol2uml.
  5. Verify you are on the correct branch. This is the most important prereq: every check diffs the on-chain deployment against the local code, so a wrong branch (or a dirty tree) silently produces meaningless results. Match the checkout to the PR head:
    • gh pr view "$PR" --json headRefName,state,mergeCommit
    • git rev-parse --abbrev-ref HEAD and git status --porcelain
    • Require the current branch to equal the PR's headRefName, OR — if the PR is already merged — that the checkout contains its merge commit (git merge-base --is-ancestor <mergeCommit> HEAD).
    • On mismatch or a dirty working tree → STOP. Tell the user to gh pr checkout <PR> (or git checkout <headRefName> / git stash) and re-run. Do not verify against the wrong code.

Step 1 — Gather PR context

  1. PR=$1. gh pr view "$PR" --json title,body,files,baseRefName,headRefName,state,url.
  2. Find the changed Foundry deploy script(s): git diff --name-only origin/master...HEAD -- 'contracts/scripts/deploy/**/*.s.sol' (or read the PR files). Ignore 000_Example.s.sol. The folder under scripts/deploy/<network>/ gives the network (mainnet, base, sonic, hyperevm, …) — use it for sol2uml --network <net> and map it to the chain deployment file (build/deployments-1.json, -8453.json, -146.json, -999.json, etc.).
  3. From each script's _execute(), enumerate every contract creation (new <Contract>(args)) and every _recordDeployment("<KEY>", address(...), type(<Contract>).name) call. Resolve <KEY> → address from the matching entry in the chain deployment JSON's contracts array (.name, .implementation). The JSON field is named implementation even for proxies and non-implementation contracts. If a newly recorded key is absent from the committed JSON, mark checks 1/3/4 ❌.
  4. The script identifier is the string passed to AbstractDeployScript("<ID>"). Resolve its proposalId, tsDeployment, and tsGovernance from the matching entry in the chain deployment JSON's executions array. Build expected governance actions from _buildGovernanceProposal() calls to govProposal.action(target, "signature(types)", abi.encode(args)). If proposalId is 0/absent while governance is expected, mark check 5 ⚠️ ("no proposalId recorded — resolve from on-chain Governor events or ask the deployer").
  5. Working set: [{key, contractType, address, constructorArgs, proposalId, network, deployScript}].

Step 2 — Run the checks

Checks 2/3/4 are per-address and independent — fan them out with parallel Task sub-agents (one per deployed contract) when there are several; otherwise run inline. Each check yields: status (✅ pass / ⚠️ needs-human / ❌ fail), one-line evidence, a details block, and a confidence (High/Med/Low). Absence of evidence is ⚠️/❌, never ✅.

1 — All deployed contracts listed in the PR description

  • Compare the Step-1 deployed name+address set against the PR body.
  • ✅ every deployed contract (name and address) appears; ❌ a deployed contract is missing; ⚠️ names present but addresses missing/ambiguous.

2 — Verified on-chain code (and dependencies) matches the codebase

  • For each deployed implementation address, from contracts/: sol2uml diff <address> .,node_modules --network <net> --apiKey "$ETHERSCAN_API_KEY" This downloads the explorer-verified source for the address and diffs it (and its dependencies) against the local checkout.
  • ✅ sol2uml reports no differences (every file identical); ❌ any file differs — quote the differing files/lines. For *Proxy addresses run the same diff against the proxy source; expect the standard proxy to match.
  • Confidence High when the diff is clean/empty.

3 — Constructor arguments are correct

  • Read the constructor expression (new <Contract>(args)) corresponding to each _recordDeployment in _execute() and resolve constants/addresses used by it.
  • Compare those arguments to the on-chain "Constructor Arguments" on the explorer (Etherscan contract page, or decode the tail of the creation tx input). Foundry's chain deployment JSON does not store constructor args or transaction hashes, so do not treat it as evidence for this check. They must match positionally.
  • ✅ all args match; ❌ any positional mismatch (show Foundry-script value vs on-chain). Proxies typically have no constructor args — note [].
Show full SKILL.md (413 more words)Show less

4 — The initialize / interaction tx matches the deploy script

  • If _execute() performs a post-deploy call — typically a proxy initialize(...)/_initialize(...) — locate the corresponding on-chain tx (explorer tx list for the proxy address, or the proxy's deployment receipt) and confirm the arguments match the Foundry script.
  • ✅ the initialize tx args match the script; ⚠️ the script has no init/interaction call (nothing to check); ❌ args differ (show the diff).

5 — Governance proposal matches the deploy script

  • Read the on-chain proposal directly via ethers — do NOT use pnpm ops proposal --id, it parses the id as a float and overflows on real (77-digit) proposalIds. Use the GovernorSix (addresses.mainnet.GovernorSix) ABI with the id as a BigNumber: g.state(id) and g.getActions(id) -> (targets, values, signatures, calldatas) (calldatas are selector-stripped — the signature is a separate string).
  • Build expected actions from _buildGovernanceProposal(): resolve every target through constants or resolver.resolve("<KEY>") and the chain deployment JSON, keep the signature passed to govProposal.action, and evaluate the corresponding abi.encode arguments to compare against each on-chain calldata.
  • ✅ identical (same count, targets, signatures, calldatas); ❌ any divergence (show it). Report the proposal state: Executed for a fully-executed deploy; Pending/Active/ Queued is normal when reviewing before execution — flag it but it is not a failure.

6 — Smoke tests after fork execution — SKIPPED (per project decision). Mark N/A.

Step 3 — Synthesize

Verdict = VERIFIED only if checks 2,3,4,5 are ✅ (check 1 may be ⚠️ if the sole gap is documentation; check 4 may be ⚠️ if there is genuinely no init/interaction call). Any ❌ in 2–5, or an unresolved ⚠️, → BLOCKERS FOUND. Emit the report:

# Deployment PR Verification — #<PR> (<title>)
Verified against: <branch>@<short-sha>
Foundry script(s): <list>   |   Network: <net>   |   Proposal: <proposalId>
Verdict: <VERIFIED | BLOCKERS FOUND>

- [<✅|⚠️|❌>] 1. All deployed contracts listed in PR description — <evidence> (conf)
- [<✅|⚠️|❌>] 2. Verified code (+deps) matches codebase (sol2uml diff) — <evidence> (conf)
- [<✅|⚠️|❌>] 3. Constructor args correct — <evidence> (conf)
- [<✅|⚠️|❌>] 4. Initialize/interaction tx matches deploy script — <evidence> (conf)
- [<✅|⚠️|❌>] 5. Governance proposal matches deploy script — <evidence> (conf)
- [⏭️] 6. Smoke tests — skipped (N/A)

## Details
### 2. sol2uml diff   <per-address: address, clean/diff, differing files>
### 3. Constructor args   <per-address: Foundry-script args vs on-chain args>
### 4. Initialize tx   <tx hash, decoded args vs Foundry-script args>
### 5. Proposal diff   <on-chain getActions vs script actions, or "identical">

## Human still owes (manual)
- Off-chain Safe/multisig follow-ups noted in the Foundry script.
- That the PR's stated intent matches the on-chain effect (judgment).
- Anything marked ⚠️ above.

Notes / common false positives

  • For sol2uml diff, run from contracts/ and source .env first so $ETHERSCAN_API_KEY is set; use --network matching the deploy folder (base→base, sonic→sonic, etc.).
  • A proxy address will not match an implementation's source — diff a *Proxy against the proxy contract, not the impl.
  • A clean sol2uml diff (no file differences) is the pass signal for check 2; treat any reported file difference as ❌ pending human review, not a warning.
  • If proposalId is 0/absent, do not fabricate one — mark check 5 ⚠️ and ask the deployer.
  • deployments/<network>/*.json remains a Talos compatibility registry, not the source of truth for Foundry deployment execution. Use build/deployments-<chainId>.json for Foundry-recorded names, addresses, and execution metadata.
  • If a helper command errors/rate-limits, retry once, then mark that check ⚠️ "tool error" with the stderr tail and continue the others. Never silently pass.

Do NOT

  • Never send transactions, never re-run the deployment, never edit files. Explorer + read-only RPC only.
  • Never declare VERIFIED while any of checks 2–5 is ❌ or an unresolved ⚠️.

© OriginProtocol, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/verify-deployment-pr of OriginProtocol/origin-dollar.

Open the folder on GitHubat commit 1be34f7

Compare with similar skills

Verify Deployment PR next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Verify Deployment PR compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Verify Deployment PR this skillOriginProtocol/origin-dollar153—~2.6kAutomated safety check: NotesMIT
Update Qmyc-software/qm15k—~1.8kAutomated safety check: PassMIT
Vercel Deploy Previewjeremylongshore/tons-of-skills-marketplace2.8k—~1.6kAutomated safety check: PassMIT
Nestjs Git Commit PR Messageaiskillstore/marketplace430—~2.4kAutomated safety check: PassMIT
Foundry Deploy Fixturesaviggiano/security144—~634Automated safety check: PassMIT
Finding TriageHacktronAI/skills115—~2.9kAutomated safety check: NotesMIT

Similar skills

  • Update Qm

    yc-software/qm

    Update a QM source fork by merging upstream, or upgrade a package deployment dependency, and open a PR.

    15k GitHub stars~1.8k tokensUpdated today
    DevOps & CloudAuto-check passed
  • Vercel Deploy Preview

    jeremylongshore/tons-of-skills-marketplace

    Create and manage Vercel preview deployments for branches and pull requests.

    2.8k GitHub stars~1.6k tokensUpdated today
    DevelopmentAuto-check passed
  • Nestjs Git Commit PR Message

    aiskillstore/marketplace

    Prepares and publishes intentional Git changes for NestJS projects.

    430 GitHub stars~2.4k tokensUpdated today
    DevelopmentAuto-check passed
  • Foundry Deploy Fixtures

    aviggiano/security

    Create or refactor Foundry deployment fixtures for Solidity tests.

    144 GitHub stars~634 tokensUpdated 22 days ago
    Backend & APIsAuto-check passed
  • Finding Triage

    HacktronAI/skills

    Interactively validate and triage Hacktron findings against the actual source code and (optionally) a live deployment, separate true positives from false positives, adjust severity, then either…

    115 GitHub stars~2.9k tokensUpdated 4 mo ago
    Backend & APIsAuto-check: notes
  • New Config

    lidofinance/diffyscan

    Creates or extends a Diffyscan verification config for a deployed contract or deployment.

    142 GitHub stars~1k tokensUpdated yesterday
    Backend & APIsAuto-check passed

More from OriginProtocol/origin-dollar

  • Fork Test

    OriginProtocol/origin-dollar

    Generate Foundry fork tests for contracts that need real on-chain integration coverage.

    153 GitHub stars~1.2k tokensUpdated today
    Auto-check passed
  • Organize Test

    OriginProtocol/origin-dollar

    Reorganize Foundry test files (.t.sol) for readability and consistency without changing semantics.

    153 GitHub stars~3.7k tokensUpdated today
    Auto-check passed
  • Smoke Test

    OriginProtocol/origin-dollar

    Generate Foundry smoke tests that validate deployment health using DeployManager/Resolver against real on-chain state with pending governance applied.

    153 GitHub stars~1.6k tokensUpdated today
    Auto-check passed
  • Commit

    OriginProtocol/origin-dollar

    Handle git commits with auto-staging, targeted pre-commit formatting, and Conventional Commit messages.

    153 GitHub stars~850 tokensUpdated today
    Auto-check: warnings
  • Talos Action Development

    OriginProtocol/origin-dollar

    Develop, modify, review, and maintain standalone Talos actions in contracts/tasks/actions, including chain guardrails, contract bindings, transaction safety, schedules, action catalogues, and Talos…

    153 GitHub stars~896 tokensUpdated today
    Auto-check passed
  • Unit Test

    OriginProtocol/origin-dollar

    Generate Foundry unit tests for a contract using this repository's conventions, structure, and naming.

    153 GitHub stars~1.6k tokensUpdated today
    Auto-check passed

Works with

Questions about Verify Deployment PR

What does Verify Deployment PR do?

Verifies a POST-EXECUTION mainnet (or other network) smart-contract deployment PR for this repo: confirms every deployed contract is listed in the PR description, that the on-chain verified source…. Verify Deployment PR is an agent skill from OriginProtocol/origin-dollar. Verifies a POST-EXECUTION mainnet (or other network) smart-contract deployment PR for this repo: confirms every deployed contract is listed in the PR description, that the on-chain verified source (and its dependencies) matches the codebase via sol2uml diff, that constructor args and the initialize tx match the Foundry script, and that the on-chain governance proposal matches the script's actions.

When should I use Verify Deployment PR?

Verify Deployment PR fits situations like: asked to review; sign off on an executed deployment PR.

How do I install Verify Deployment PR in Claude Code?

Run `npx skills add OriginProtocol/origin-dollar --skill verify-deployment-pr -a claude-code`. Or copy the skill folder (.claude/skills/verify-deployment-pr in OriginProtocol/origin-dollar) into .claude/skills/verify-deployment-pr in your project. Claude Code loads it when a task matches its description.

How do I install Verify Deployment PR in Codex?

Run `npx skills add OriginProtocol/origin-dollar --skill verify-deployment-pr -a codex`. Or copy the skill folder (.claude/skills/verify-deployment-pr in OriginProtocol/origin-dollar) into .agents/skills/verify-deployment-pr in your project. Codex loads it when a task matches its description.

Can I use Verify Deployment PR in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add OriginProtocol/origin-dollar --skill verify-deployment-pr -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/verify-deployment-pr, .gemini/skills/verify-deployment-pr, .github/skills/verify-deployment-pr and .opencode/skills/verify-deployment-pr in your project.

What does Verify Deployment PR need to run?

Going by SKILL.md and its folder, Verify Deployment PR needs the command-line tools its instructions call (git, gh, npm and pnpm) and credentials named ETHERSCAN_API_KEY. Our summary lists: Node.js; A credential in ETHERSCAN_API_KEY. Its frontmatter pre-approves these tools: Bash, Read, Grep, Glob, Task.

Does Verify Deployment PR access the network?

SKILL.md contains no URLs. Its commands use git, gh and npm, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Verify Deployment PR safe to install?

Our automated static check of SKILL.md found notes only (mentions a .env file; pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Verify Deployment PR use?

Verify Deployment PR is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Verify Deployment PR use?

About 2.6k tokens (SKILL.md is roughly 10k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Verify Deployment PR?

Skills that share tags, products or a category with Verify Deployment PR: Update Qm (yc-software/qm, 15k stars), Vercel Deploy Preview (jeremylongshore/tons-of-skills-marketplace, 2.8k stars), Nestjs Git Commit PR Message (aiskillstore/marketplace, 430 stars) and Foundry Deploy Fixtures (aviggiano/security, 144 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Verify Deployment PR?

OriginProtocol (a GitHub organization) maintains it in OriginProtocol/origin-dollar, which has 153 GitHub stars. The repository holds 7 skills in this directory. The repository was last updated on October 7, 2026.

Source: OriginProtocol/origin-dollar on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.