release-gate

Enforces structured sign-off before irreversible actions. Use explicitly before systemctl restarts, file deploys, DB migrations, public launches, pricing changes, or emails to real users. Requires named reviewer roles (Dev, QA, Legal, Product) with explicit pass/fail per checklist item. Logs every decision. Does NOT auto-trigger on ambiguous actions — only invoke when the action is clearly irreversible.

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

Permissions Required

This skill:

• Reads nothing automatically
• Writes to a log file you specify (append only)
• Does NOT read env files, system state, or external services
• Does NOT modify AGENTS.md or any agent config

When to Use This Skill

Read this skill before any action that is:

• Hard to reverse — systemctl restart, DB migration, file deploy, data deletion
• Customer-facing — public launches, website updates, pricing changes
• High-stakes — payments, emails to real users, legal documents going live
• Team-coordinated — requiring multiple agents or humans to align first

Quick Start

text

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

Minimal Gate (single reviewer)

text

## 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)

text

## 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

markdown

# 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

text

[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

text

[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

python

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. When in doubt, ask the user before acting — do not self-invoke the gate on ambiguous actions.

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

python

# In your agent task, before any deploy command:
# Each item requires explicit passed=True — False or missing = BLOCKED
gate_passed = run_release_gate(
    feature="Add subscription billing",
    required_roles=["Dev", "Product"],
    checklist={
        "Dev": [
            {"item": "Tests pass", "passed": True},
            {"item": "No hardcoded secrets", "passed": True},
            {"item": "Migration safe", "passed": True},
        ],
        "Product": [
            {"item": "Pricing page updated", "passed": True},
            {"item": "Copy accurate", "passed": True},
        ],
    },
    log_file="/your/logs/deployments.log",
    deployer="agent",
)
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

• Does NOT enforce blocking at runtime — there is no code that physically prevents a deploy. The gate works because the agent is instructed to treat it as a hard rule.
• Does NOT detect if the gate was bypassed — if an agent skips the checklist, nothing will catch it automatically. The log is your only audit trail.
• Does NOT handle concurrent approvals — if two agents approve simultaneously, last-write-wins on the log. For multi-agent teams, serialize gate runs.
• Does NOT recover from failed logging — if the log write fails, the deploy decision is unrecorded. Always verify the log entry was written before proceeding.

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

• OWASP Secure Deployment Checklist: https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/
• 12-Factor App deployment: https://12factor.net/

---

Custom implementations and questions: [e-mail]