Skip to content
cccskills
FreePublished on GitHub

vibe-safe-deploy

Performs deployment with pre-flight checks, atomic replacement, post-deploy verification, provenance (proving the environment serves the exact commit you pushed), and automatic rollback. Use before any deployment to staging, preview, or production.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md2.9 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

vibe-safe-deploy

Ship with confidence. Every deployment should be verifiable and reversible.

When to Use This Skill

  • Deploying to staging or production environments
  • Releasing a new version
  • Deploying infrastructure changes

When NOT to Use This Skill

  • Local development builds
  • CI/CD that already handles these checks
  • Deploying documentation (low risk)

Pre-Flight Checklist

Before deploying, verify:

  • All tests pass (including integration tests)
  • Linting is clean
  • No uncommitted changes in working tree
  • No secrets in the diff (grep -r 'API_KEY\|SECRET\|PASSWORD')
  • Build succeeds
  • Database migrations are reversible (if applicable)

Steps

  1. Pre-flight checks — Run all items in checklist. Stop if any fail.

  2. Backup current state:

    cp -r current_deploy/ current_deploy.prev/
    # or: docker tag app:current app:rollback
    
  3. Deploy using atomic operations:

    # Use 'install' not 'cp' for atomic file replacement
    install -m 755 new_binary /path/to/binary
    # or: docker tag app:new app:current && docker-compose up -d
    
  4. Health check (within 60s timeout):

    • Service starts successfully
    • Health endpoint returns 200
    • Key functionality works (smoke test)
    • No error spikes in logs
  5. If health check fails → automatic rollback:

    cp -r current_deploy.prev/ current_deploy/
    # Restart services with previous version
    
  6. Verify provenance. "Deploy succeeded" means a job finished, not that the new build is being served.

    • Bake the commit SHA into the build or image and serve it at a version endpoint (for example /version.txt)
    • After deploy, poll that endpoint until it returns the expected SHA; on timeout, fail and report the SHA it actually served
    • Keep environments separate: branch pushes deploy preview (behind auth, noindex), and only the main branch deploys production
    • Give the deploy credential the least privilege that works (for example a forced-command SSH key that accepts only <environment> <sha>)
  7. Report status: success / failed / rolled-back

Output Format

Deployment Report

Status: SUCCESS / FAILED / ROLLED_BACK Version: [version or commit hash] · Served SHA: [value from version endpoint] Duration: [time]

StepStatusDuration
Pre-flight✓5s
Backup✓2s
Deploy✓10s
Health check✓15s

Post-Deploy Verification

  • Service running: ✓
  • Health endpoint: 200 OK
  • Log errors: 0 in last 60s

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Validates completed work against defined acceptance criteria. Use after completing a task that has specific success criteria defined in issues, specs, or task descriptions.

The English summary is being prepared. Showing the original description.

ash1794/vibe-engineering164Updated Oct 8, 2026

Generates edge case, failure mode, and spec-driven test cases. Covers boundary values, nil inputs, concurrency, resource exhaustion, malformed data, and requirement-linked traceability tests. Use after happy-path tests exist and before claiming coverage is complete, when requirements lack tests, or before a security review.

The English summary is being prepared. Showing the original description.

ash1794/vibe-engineering164Updated Oct 8, 2026

Catches shortcuts and reward hacking — weakening or deleting tests to make them pass, hard-coding expected outputs, silently dropping requirements, or claiming work is done without running it. Use before declaring a task complete and whenever a test or requirement feels like it's in the way.

The English summary is being prepared. Showing the original description.

ash1794/vibe-engineering164Updated Oct 8, 2026

Safely integrates commits from parallel agent branches using sequential cherry-pick. Use after parallel work completes in isolated branches or worktrees.

The English summary is being prepared. Showing the original description.

ash1794/vibe-engineering164Updated Oct 8, 2026

Audits tests for concurrency safety — race conditions, shared mock state, cleanup ordering. Use when writing tests that involve goroutines, async operations, or shared mutable state.

The English summary is being prepared. Showing the original description.

ash1794/vibe-engineering164Updated Oct 8, 2026

Enforces tiered test coverage standards with three dimensions — line coverage by tier, spec-to-test traceability, and spec-to-code implementation mapping. Use before claiming code is complete.

The English summary is being prepared. Showing the original description.

ash1794/vibe-engineering164Updated Oct 8, 2026

See all skills by ash1794

Report a problem with this skill