Deployment Gate Skill

Purpose

Production is shared and live. This gate exists because agents are very good at cleaning everything and starting over — and on shared infrastructure, that instinct is an outage. Autonomy here is not granted; it is gated into existence.

The prime directive

No delete. No remove. No recreate-from-scratch. Only removals that are strictly necessary and explicitly listed in the approved plan may run. If an operation would delete, drop, scale-to-zero, or recreate any resource not explicitly listed: STOP. Ask the Leader.

Protocol — every deployment

1. Assess first, deform nothing. Before planning, inspect the current environment. The plan must deploy into the existing configuration without changing unrelated resources.
2. Write the full command manifest. Every command that will run, in order, before anything runs. No composing commands mid-deployment.
3. Prefer standard commands. Draw from references/standard-commands.md — the vetted vocabulary of deployment operations. A command outside the standard set must be flagged as NON-STANDARD in the manifest.
4. Advisor go/no-go. Spawn an advisor agent with this skill and the manifest. The advisor checks each command against the checklist below and returns GO or NO-GO per command. Any NO-GO halts the deployment.
5. Leader approval when required. First deployment of a new kind, any NON-STANDARD command, anything touching the database, and anything on the prime directive's boundary: Leader approves before execution.
6. Execute exactly the approved manifest. If reality diverges (a command fails, output is unexpected), STOP — do not improvise recovery. Report, re-plan, re-gate.
7. Verify. Run the post-deploy checks (health endpoints, smoke tests, migration status). Record everything in a production release record per the documentation skill.

Advisor checklist

• Every command is in the manifest; nothing improvised.
• No command violates the prime directive; necessary removals are itemized and justified.
• Namespace/context is explicit on every command — nothing runs against a default context.
• Database changes are versioned migrations, run via the standard containerized initialization, never DDL snapshots or hand-edits.
• Secrets/certificates handled per plan: correct location, never echoed, never logged, never committed.
• Network exposure follows the allow-list; no port or ingress opened beyond the plan.
• Rollback steps exist and are as concrete as the deploy steps.
• Blast radius stated: what could this touch beyond the target application?

Failure stance

Uncertain → NO-GO. On shared infrastructure, the cost of a wrongly stopped deployment is minutes; the cost of a wrongly passed one is other people's applications.

Bundled resources

• references/standard-commands.md — the vetted command vocabulary (create/edit for your environment).