agentsclimarketplace

Deployment workflow

Skill sairam0424/MindForge/.mindforge/skills/deployment-workflow

MindForge: The Enterprise Agentic Framework for Claude Code & Antigravity. High-performance autonomous execution, wave-parallelism, and multi-tier governance for production-grade AI engineering.From the repository description

Install
npx -y skills add sairam0424/MindForge --skill deployment-workflow

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.1 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it

Skill — Deployment Workflow (Staged Production Release Pipeline)

When this skill activates

When deploying code to staging or production, planning a release, setting up feature flags, or managing rollback strategies. Use for any transition from "code is ready" to "code is live and monitored." Covers the full lifecycle from pre-deploy verification through post-deploy health confirmation.

Core principle: Never deploy blind — every release has a rollback plan, success thresholds, and monitoring before it is considered complete.

Mandatory actions when this skill is active

Before deployment begins

  1. Select depth level based on risk:

    LevelTimeWhen to useScope
    Quick5-10 minHotfix, docs, configGit clean + tests only
    Standard15-30 minFeature, refactorFull pipeline
    Deep30-60 minBreaking change, infraBackup + load test + canary
  2. Pre-deploy checklist (all levels):

    • Working directory is clean (git status shows no uncommitted changes)
    • All tests pass (npm test / pytest / equivalent)
    • No lint errors or type errors
    • CHANGELOG updated with version and summary
    • Branch is rebased on latest main
    • PR approved (if applicable)
  3. Risk assessment:

    • Does this touch auth, payments, or PII? (triggers security review)
    • Does this require a database migration? (adds rollback complexity)
    • Does this change public API contracts? (requires versioning)
    • What is the blast radius if this fails? (single user vs all users)

During deployment

Phase 1 — Build & Bundle:

  • Compile/transpile all source
  • Run type checker (zero errors required)
  • Bundle analysis: warn if any chunk exceeds 250KB
  • Generate source maps for production debugging
  • Tag commit with version: git tag v[X.Y.Z]

Phase 2 — Staging:

  • Deploy to staging environment
  • Run health check endpoint (HTTP 200 within 30s)
  • Execute smoke test suite (critical paths only)
  • Verify environment variables are set correctly
  • Check database connectivity and migration status

Phase 3 — Production (select strategy):

StrategyUse whenProcess
QuickLow risk, fast rollbackDeploy all at once, monitor 5 min
RollingMedium riskReplace instances 25% at a time, 2 min between
CanaryHigh risk, new feature5% → 25% → 50% → 100%, monitor at each step

Phase 4 — Monitoring (mandatory for all strategies):

  • Watch error rates for 15 minutes post-deploy
  • Compare P95 latency to pre-deploy baseline
  • Check business metrics (conversion, signup, core actions)
  • Verify no new error types in exception tracker

Decision thresholds:

GREEN (proceed):  Error rate < 10% above baseline
YELLOW (investigate): Error rate 10-100% above baseline
RED (rollback):   Error rate > 2x baseline OR P95 > 3x baseline

Feature flag lifecycle (when applicable):

DEPLOY (flag OFF) → ENABLE (team only) → CANARY (5% users) →
GRADUAL (25% → 50% → 75%) → FULL (100%) → CLEANUP (remove flag)
  • Each stage requires minimum 1 hour soak time (24 hours for GRADUAL steps)
  • Monitor flag-specific metrics at each stage
  • Rollback = disable flag (instant, < 1 minute)

After deployment

  1. Health verification:

    • All health endpoints return 200
    • Error rate < 1% (absolute, not relative)
    • No new exception types in monitoring
    • P95 latency within acceptable range
    • Business metrics stable (no cliff)
  2. Rollback procedures (know these BEFORE deploying):

    MethodTimeWhen to use
    Feature flag disable~1 minFlag-guarded changes
    Git revert + redeploy~5 minCode-only changes
    Database rollback~15 minMigration-dependent changes
  3. Post-deploy documentation:

    • Update DEPLOYMENT.md with:
      • Phase timestamps (start, staging, production, verified)
      • Commit hash deployed
      • Strategy used
      • Any issues encountered and resolution
      • Final status: SUCCESS / ROLLED_BACK / PARTIAL
  4. Metrics baseline:

    • Record current performance metrics as new baseline
    • Archive previous baseline for comparison
    • Update alerting thresholds if performance improved

Self-check before task completion

Before marking a deployment task done:

  • Did I verify all pre-deploy checks pass (tests, lint, types)?
  • Did I document the rollback plan BEFORE deploying?
  • Did I set up monitoring and define success thresholds?
  • Did I wait the minimum soak time before declaring success?
  • Did I record the deployment in DEPLOYMENT.md with timestamps?
  • Is the error rate below 1% post-deploy?
  • Did I update the metrics baseline?
  • If using feature flags: is the cleanup step scheduled?

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 326,144. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.