ai-Release and Deploy

Mission

Turn an approved, independently reviewed release into a controlled, observable, and recoverable deployment without unauthorized remote actions.

Use this skill when

• Work is ready for branch, commit, pull request, merge, tag, release, or deployment.
• CI/CD, artifact packaging, release notes, staged rollout, post-deploy checks, or a planned rollback are needed.
• An approved deployment attempt failed before or during rollout and the predefined release rollback procedure must be executed; active user-impacting incidents route to ai-incident-response.

Do not use this skill when

• Requirements, implementation, applicable tests, security review, or independent review are materially incomplete.
• The user has not approved the specific remote, public, paid, destructive, or production action.
• A current ai-production-readiness-reviewer decision is missing for a material production release when that specialist is installed.
• A production incident is active; use ai-incident-response.

Approval boundary

Explicit approval is required before push, force operation, history rewrite, branch deletion, merge, tag, release publication, infrastructure change, secret change, migration on real data, paid service use, or deployment. Approval for one action does not imply approval for later actions.

Readiness input

For a material production release, consume a current ai-production-readiness-reviewer result for the exact commit, artifact, configuration, migration set, and target environment. Confirm that conditions and approvals remain satisfied. Do not independently certify readiness or silently waive a blocker.

For low-risk preview or staging work where the full reviewer is not installed, verify the applicable release prerequisites and label the decision as a deployment precheck rather than independent production certification.

Safe Git and CI/CD

1. Inspect branch, remotes, status, diff, conflicts, and untracked files.
2. Preserve user changes; never reset, discard, clean, rebase, or overwrite them silently.
3. Use a feature branch and reviewable commits where practical.
4. Prepare a PR with scope, evidence, risks, screenshots, migrations, rollout, and rollback.
5. Use least-privilege CI permissions, protected environments, reviewed secrets, pinned or controlled third-party actions, and reproducible checks.
6. Never bypass hooks, use --force, or publish secrets to make a pipeline pass.

Supply-chain and artifacts

Read references/supply-chain-release.md. Generate checksums for distributable artifacts. Produce an SBOM or provenance record when risk and tooling justify it. Verify that source, dependency lockfiles, build inputs, and artifacts correspond to the intended version.

Deployment workflow

1. Confirm exact environment, service, version, owner, cost, and rollback target.
2. Validate configuration without printing secrets.
3. Back up and test restore before risky data changes.
4. Deploy to preview/staging first when available; use canary or phased rollout for higher risk.
5. Run smoke checks and critical user journeys.
6. Observe logs, metrics, error rates, latency, and business/user-impact indicators for a defined window.
7. Record version, commit, artifact checksum, migration state, deployment time, evidence, and unresolved risk.

Load the relevant playbook:

• references/git-ci.md
• references/deployment.md
• references/rollback-incident.md for release rollback mechanics only; active incident command belongs to ai-incident-response.

Rollback mode

Trigger rollback on failed health checks, severe error increase, broken critical journeys, data corruption risk, security exposure, or predefined stop conditions. Stop rollout, preserve evidence, execute the verified rollback, validate recovery, and communicate known facts.

Output contract

release_result:
  result: PREPARED | DEPLOYED | PARTIALLY_DEPLOYED | ROLLED_BACK | BLOCKED
  version: <version or null>
  commit: <commit or null>
  approvals: []
  checks: []
  artifacts_and_checksums: []
  deployment_target: <environment or null>
  readiness_input: <review reference or scoped precheck>
  monitoring_evidence: []
  rollback_status: <ready | tested | executed | unavailable>
  unresolved_risks: []
  recommended_next_skill: <canonical id or null>

Create or update .vibeguard/RELEASE.md.

Specialist boundaries added in 0.8.0

• Route active production incidents to ai-incident-response.
• Require ai-production-readiness-reviewer before a material production release when that skill is installed.
• Route observability design gaps to ai-observability-and-reliability and disaster recovery gaps to ai-disaster-recovery.
• This skill owns release mechanics and approved deployment, not independent readiness certification or incident command.

Completion protocol

• Return one standardized status: completed, completed_with_warnings, partial, blocked, failed, needs_approval, or needs_user_input.
• Support every success claim with observable evidence; distinguish facts, assumptions, and unverified items.
• Record material commands, files, artifacts, approvals, and remaining risks without exposing secrets or hidden reasoning.
• Recommend one next skill only when another step is actually required.
• Stop after the defined outcome, an approval gate, a genuine blocker, or the retry budget is exhausted.

Result-strengthening protocol

Before claiming completion: (1) restate the measurable outcome, (2) execute only within the approved scope, (3) verify with observable evidence, (4) actively challenge the result for regressions, missing cases, and unsupported assumptions, and (5) report status using the shared result schema. High-risk work requires an independent challenge pass or a documented reason it could not be performed.

Quality gate

• No remote or production action occurred without specific approval.
• Release claims are backed by actual source, command, artifact, and environment evidence.
• Supply-chain, backup, rollback, and monitoring controls are proportionate to risk.
• Post-deploy critical journeys and health indicators passed, or rollback occurred.
• The user receives a plain-language result and exact verification/recovery information.