Release Gate

Release Gate

A lightweight, configurable deployment gate for AI agents. Enforces structured sign-off before irreversible actions — no deploy without explicit checklist completion.

When to Use This Skill

Read this skill before any action that is:

Quick Start

Before deploying: run through the release gate checklist.
Block if any item is unchecked. Log the result either way.

Minimal Gate (single reviewer)

## Release Gate — [Feature Name]
Dev Sign-Off
[ ] Code is tested and working
[ ] No regressions in existing functionality
[ ] Secrets and credentials are not hardcoded
Final Check
[ ] All boxes above are checked
[ ] Deployer: [name/agent]
If any box is unchecked: BLOCK. Fix first, then re-run.

Full Gate (multi-role)

## Release Gate — [Feature Name]
Date: YYYY-MM-DD
Deployer: [agent or human name]
Dev Sign-Off
[ ] Feature built and tested end-to-end
[ ] No existing routes/endpoints broken
[ ] DB migrations are safe and additive (no destructive schema changes)
[ ] Security review: auth, input validation, IDOR, rate limiting
Product / Copy Sign-Off
[ ] Feature is represented on the website/UI
[ ] Copy accurately describes what the code does
[ ] No website copy for features that don't exist yet in code
[ ] Pricing is consistent across all pages/surfaces
Legal / Compliance Sign-Off (if applicable)
[ ] Privacy policy covers this feature
[ ] Regulatory requirements checked (TCPA, GDPR, COPPA, etc.)
[ ] Any third-party terms reviewed
Final Check
[ ] All roles above are aligned
[ ] No open blockers
[ ] Log entry written to deployments.log
If any box is unchecked: BLOCK THE DEPLOY. Align first.

Roles — Customize for Your Team

| Role | Responsibility | |------|---------------| | Dev | Code quality, tests, security | | Product | UI/copy matches code, pricing consistency | | Legal | Compliance, terms, privacy | | QA | Regression testing, edge cases | | Finance | Pricing, billing, refund policies |

Define only the roles relevant to your project. A solo dev only needs Dev + Final Check.

Configuring Your Gate

Copy the template that fits your project into your workspace as DEPLOY_GATE.md (or inline it in your project's AGENTS.md). Customize the checklist items and role names.

Example: SaaS Startup

# Deploy Gate — MyApp
Roles
Dev: code, security, DB
Product: copy, pricing, UI
Legal: privacy, compliance
Trigger On
systemctl restart myapp
Changes to app.py, models.py, templates/
Any update to landing_page.html
Pricing changes
Gate Checklist
Dev
[ ] Tested locally + staging
[ ] DB migration safe (additive only)
[ ] No hardcoded secrets
Product
[ ] Website matches new feature
[ ] Pricing pages updated if needed
Orchestrator
[ ] Dev + Product aligned
[ ] Log entry written
Log File
/opt/myapp/logs/deployments.log

Logging

Every gate run — pass or block — must be logged.

Log Format

[2026-03-30 04:00 UTC] DEPLOY: Add Stripe checkout
  Feature: Stripe payment integration v1
  Dev: PASS | Product: PASS | Legal: PASS
  Deployer: [agent or human]
  Result: APPROVED — systemctl restart myapp executed

[2026-03-30 04:00 UTC] BLOCKED: Add Stripe checkout
  Feature: Stripe payment integration v1
  Dev: PASS | Product: BLOCKED (pricing page not updated)
  Deployer: [agent or human]
  Result: BLOCKED — deploy held until Product role updates pricing page

Python logging helper

from scripts.release_gate import log_gate_decision
log_gate_decision(
    log_file="/opt/myapp/logs/deployments.log",
    feature="Stripe checkout v1",
    roles={"Dev": "PASS", "Product": "PASS", "Legal": "PASS"},
    result="APPROVED",
    deployer="[your agent or name]",
    notes="systemctl restart myapp"
)

Hard Rules

1. Any unchecked box = BLOCK. Do not deploy with open items. 2. No "I'll fix it after the deploy." Fix first. Gate second. Deploy third. 3. Log every decision — pass and block. The log is the audit trail. 4. Gate applies to rollbacks too. A rollback is still a deploy. 5. If you're unsure whether something needs a gate: it does.

Anti-Patterns to Avoid

❌ "It's just a small change" — small changes break prod ❌ "I'll update the copy after" — website must match code on deploy ❌ Skipping Legal row for features that touch user data ❌ Not logging blocks — partial logs hide patterns ❌ Running the gate mentally without writing it down

Integration With Agent Workflows

Pre-deploy hook pattern

# In your agent task, before any deploy command:
gate_passed = run_release_gate(
    feature="Add subscription billing",
    required_roles=["Dev", "Product"],
    checklist={
        "Dev": ["tests pass", "no hardcoded secrets", "migration safe"],
        "Product": ["pricing page updated", "copy accurate"],
    }
)
if not gate_passed:
    raise RuntimeError("Release gate not cleared. Blocking deploy.")

With deploy-gate skill

If your project already uses the deploy-gate skill, this skill provides the underlying pattern and logging utilities. deploy-gate is a project-specific instantiation of release-gate.

What This Skill Does NOT Do

This is a structured convention enforced by agent instruction, not a runtime enforcement system. That is intentional — the same model used in professional engineering workflows (PR checklists, DORA gates, SOC2 change management). The discipline is the mechanism.

References

Before deploying: run through the release gate checklist.
Block if any item is unchecked. Log the result either way.

Minimal Gate (single reviewer)

```