release-config-management

Standardize multi-chain deployment configuration, environment secrets, ABI versioning, and database migrations.

Updated Jul 28, 2026
One-click install
npx skills add https://github.com/IagoPrandi/zeroclaw-plugin --skill release-config-management-iagoprandi
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: release-config-management
Source: https://github.com/IagoPrandi/zeroclaw-plugin/tree/main/.claude/skills/release-config-management
Command: npx skills add https://github.com/IagoPrandi/zeroclaw-plugin --skill release-config-management-iagoprandi

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Multi-chain and multi-environment releases often break because contract addresses get hardcoded, secrets leak into commits, ABI changes desynchronize contracts from indexers and apps, and database migrations are not idempotent. This Skill enforces a consistent release and configuration management process so every deployment is reproducible and auditable. ## Core Features & Use Cases - Canonical config layout: Persists contract addresses, deploy block numbers, commit hashes, and timestamps per chain in deployments/<chainId>.json, with .env.example holding keys only and secrets injected at runtime. - ABI/schema versioning workflow: Coordinates a five-step sequence (regenerate ABI artifacts, update Ponder handlers, add DB migration, update API/app types, replay/reorg sanity tests) on every event or ABI change. - Idempotent dbmate migrations: Requires forward-only, lock-reviewed migrations followed by Kysely type regeneration. - Use Case: When a PR changes a contract event, use this Skill to verify the indexer handlers, DB migration, app types, and deployment checklist (deploy, explorer verification, smoke E2E) are all updated before merging. ## Quick Start Review this pull request that changes deploy scripts and a contract event against the release and configuration management checklist.

Frequently Asked Questions about release-config-management

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I manage smart contract deployment addresses across multiple chains?▼

Store addresses per chainId in a deployments/<chainId>.json file that records the contract address, dependencies, deploy block number, git commit hash, and timestamp. Never hardcode addresses in frontend or backend code; apps should read chainId and addresses from this canonical config.

What steps are required when a contract ABI or event changes?▼

An ABI or event change requires five coordinated steps: regenerate ABI artifacts, update Ponder indexer handlers, add a DB migration if the schema changes, update API and app types, and run replay or reorg sanity tests. Skipping any step desynchronizes contracts, indexer, and app.

How should environment secrets be handled in deployment config?▼

Keep a .env.example file containing keys only with no values, and inject runtime secrets at runtime rather than build time. Committing .env files or secrets to the repository is explicitly forbidden.

What makes a dbmate database migration safe for production?▼

Migrations must be forward-only and idempotent, and reviewed for lock and index impact before applying. After migrations run, regenerate Kysely types if the project uses them so application code matches the new schema.

What is the minimum deployment checklist for a contract release?▼

The contract deploy must succeed on the target chainId, explorer verification is recommended, the indexer must point to the correct RPC and contract address, the app must read chainId and addresses correctly, and a smoke E2E test covering the full flow must pass.