# Release Safety

> Use before cutting or deploying a backend release (or reviewing release readiness) — backward compatibility with the current production app, testing the current app against the new backend, rollback plan, config/data readiness, feature flags & observability, and the code-comment policy for transition logic.

- **Type:** Skill
- **Install:** `agentstack add skill-kennguyen887-agent-foundation-release-safety`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [kennguyen887](https://agentstack.voostack.com/s/kennguyen887)
- **Installs:** 0
- **Category:** [Communication](https://agentstack.voostack.com/c/communication)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [kennguyen887](https://github.com/kennguyen887)
- **Source:** https://github.com/kennguyen887/agent-foundation/tree/main/skills/release-safety

## Install

```sh
agentstack add skill-kennguyen887-agent-foundation-release-safety
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Release safety

Core principle: **a backend release is valid only if the current production app keeps working after
it deploys.** Any change that breaks the current app version is an invalid release — regardless of
whether a force update is planned.

## 1. Backend backward compatibility
Every backend release MUST work with BOTH the current production app and the new app — there's always
a gap between backend deploy and app rollout.

**Database changes:**
- Only additive migrations per release (add columns, add tables).
- NEVER rename or drop columns in the same release as the feature using them.
- Sequence: add column → update reads/writes → remove old column in a later release.

**API changes:**
- Preserve existing API contracts (fields, response shapes, endpoints).
- Don't remove/break old fields or endpoints until the old app version is fully deprecated.

**Code requirement:** when introducing backward-compatible logic, add a comment explaining why it's
needed, which app versions are affected, and when the old logic/fields can be removed.

## 2. Test current app against new backend
Before every release — including force-update releases — verify the current production app version
works against the new backend. Run all critical user flows with the current app pointed at the new
backend. If any critical flow fails: block the release, fix the backend, re-test. No exceptions.

## 3. Rollback plan
Every release requires a documented rollback plan before it ships, answering:
- Can the previous backend version be redeployed safely?
- If not, what's the forward-fix strategy?
- Who is the rollback owner (authority to trigger it)?
- What are the rollback conditions (error-rate threshold, critical failure types)?

Do not release if any of the above is undefined.

## 4. Config & data readiness
- NEVER assume staging DB, config, or seed data matches production — verify explicitly.
- Validate all critical config at startup; fail fast if missing/invalid — no silent fallbacks.
- Treat code readiness, DB migration readiness, and config readiness as three separate checks.
- Explicitly verify partner settings, category mappings, plan settings, and other business config.
- Keep a golden staging/UAT dataset covering critical flows and known edge cases.
- Don't rely on staging-only assumptions or seed data in production code paths.

## 5. Feature flags & observability
- Use feature flags for high-risk business-logic changes — do not gate on `NODE_ENV`.
- Add logs and alerts on every critical rule branch, fallback path, missing config, unexpected behavior.
- Post-release verification is mandatory for critical flows — smoke-test before AND after release.

## 6. Code comment policy (transition logic)
Add code comments only when needed for: backward compatibility (affected versions + when removable),
migration safety (what state the DB must be in), release safety (deploy-order requirement), or
temporary transition logic (`TODO: remove after `).

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [kennguyen887](https://github.com/kennguyen887)
- **Source:** [kennguyen887/agent-foundation](https://github.com/kennguyen887/agent-foundation)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-kennguyen887-agent-foundation-release-safety
- Seller: https://agentstack.voostack.com/s/kennguyen887
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.