pwp-deploy
npx machina-cli add skill shandar/pwp-plugin/pwp-deploy --openclawPWP Deployment Protocol
You are now operating under the Project Workflow Protocol's deployment discipline. Follow this structured approach for every deployment task.
Context: $ARGUMENTS
Phase 1: Environment Awareness
Understand the environment ladder:
local → staging → production
| Environment | Purpose | Who Sees It | Data |
|---|---|---|---|
| Local | Dev and debugging | Developer only | Mock / seed data |
| Staging | Pre-production validation | Team / QA | Synthetic data mirroring production |
| Production | Real users | Everyone | Real data — handle with care |
Rules
- Code flows one direction: local → staging → production. Never hotfix production directly.
- Staging must mirror production config (same env vars shape, services, region).
- Database migrations run on staging first. Always.
Phase 2: Pre-Deploy Checklist
Before deploying to production, verify ALL items:
- [ ] All pre-merge verification passed (tsc, build, tests)
- [ ] Staging deployment succeeded
- [ ] Staging smoke test passed (critical user journey works)
- [ ] Database migrations tested on staging
- [ ] Environment variables verified (no missing keys)
- [ ] Feature flags configured (if progressive rollout)
- [ ] Rollback plan documented (what to revert and how)
- [ ] Team notified of deploy window
Phase 3: Choose Deployment Strategy
Direct Deploy (Solo / Small Team)
git push origin main → CI builds → auto-deploy → smoke test
When: Solo builders, early-stage, low-traffic apps.
Staged Rollout (Growth / Enterprise)
main → staging deploy → smoke test → canary (5%) → monitor → full rollout
When: Significant user base, changes with behavioral risk.
Blue-Green Deployment (Zero Downtime)
Two identical environments. Switch traffic from old (blue) to new (green). When: Zero-downtime requirement, critical production services.
Phase 4: Database Migration Safety
Migrations are the highest-risk part of deployment:
- Reversible always. Every
uphas a correspondingdown. - Two-phase column drops. Deploy code that stops using the column first. Drop column in next deploy.
- Test on production-shaped data. Not empty databases.
- Backup before migration. Automated or manual — but always before.
- Separate migration deploys from feature deploys. Don't combine schema changes with app logic.
Phase 5: Feature Flags
For changes with behavioral risk:
if (featureFlags.isEnabled('new-checkout-flow')) {
return <NewCheckout />;
}
return <LegacyCheckout />;
Rules
- Flags are temporary. Set a removal date when creating.
- Dead flags (>30 days post-full-rollout) must be cleaned up.
- Flag state tracked in central config, not scattered across code.
Phase 6: Rollback Strategy
Every deploy must have a documented rollback plan:
| Scenario | Action |
|---|---|
| Code regression | Revert commit, redeploy previous version |
| Migration failure | Run down migration, redeploy previous version |
| Config error | Fix environment variable, redeploy |
| Partial outage | Disable feature flag, investigate |
| Full outage | Revert to last known good deploy, incident response |
Speed Targets
- Code revert: Under 5 minutes (automated CI/CD redeploy)
- Migration revert: Under 15 minutes (tested
downmigration) - Full rollback: Under 30 minutes (restore from backup if needed)
Phase 7: Post-Deploy Verification
After every production deploy:
- [ ] Application loads without errors
- [ ] Critical user journey works (signup, core action, payment)
- [ ] No new errors in monitoring / error tracking
- [ ] No performance regression (response times, page load)
- [ ] Database is healthy (no locked queries, no pool exhaustion)
- [ ] Logs show expected behavior (no unexpected warnings)
Phase 8: Monitoring & Observability
Set up BEFORE you need it:
| Signal | Tool Examples | What to Watch |
|---|---|---|
| Errors | Sentry, Bugsnag, LogRocket | New error types, rate spikes |
| Performance | Vercel Analytics, Datadog | Response times, Core Web Vitals |
| Uptime | UptimeRobot, Pingdom, Better Stack | Downtime, SSL expiry |
| Logs | Structured JSON logs | Unexpected patterns, auth failures |
| Alerts | PagerDuty, Opsgenie, Slack | Threshold breaches |
Alert Thresholds
- Error rate > 2x baseline → Slack notification
- Error rate > 5x baseline → Pager alert
- Uptime check fails → Immediate alert
- Response time > 3x baseline → Warning
Quick Checklist
- Environment ladder defined
- Pre-deploy checklist completed
- Database migrations tested on staging
- Rollback plan documented
- Post-deploy verification passed
- Monitoring active and alerting configured
- Feature flags have removal dates
Source
git clone https://github.com/shandar/pwp-plugin/blob/main/skills/pwp-deploy/SKILL.mdView on GitHub Overview
PWP deployment protocol provides a structured, environment-aware process for releasing from local to production with safety checks, staging validation, and rollback plans. It emphasizes a one-way flow, rigorous pre-deploy checks, strategy choices, and post-deploy verification to reduce risk.
How This Skill Works
It defines an Environment ladder (local → staging → production), requires a complete pre-deploy checklist, and prescribes deployment strategies (direct, staged rollout, or blue-green). It also enforces safe database migrations, temporary feature flags, and formal rollback plans to ensure observable, reversible releases.
When to Use It
- Deploying to production or going live
- Planning a pre-deploy check or rollback plan
- Choosing a deployment strategy (direct, staged, blue-green)
- Handling database migrations safely
- Using feature flags or verifying post-deploy status
Quick Start
- Step 1: Verify staging mirrors prod and run pre-deploy checks
- Step 2: Choose a deployment strategy and deploy to the chosen environment
- Step 3: Monitor post-deploy, verify critical user journeys, and enact rollback if needed
Best Practices
- Always follow the environment ladder and mirror prod in staging
- Complete the pre-deploy checklist before production
- Test migrations on production-like data; back up beforehand
- Use feature flags for risky changes and track centrally
- Document rollback steps and notify the team of deploy window
Example Use Cases
- Direct deploy of a low-traffic service after staging validation
- Blue-green switch for a production API with zero downtime
- Canary rollout starting at 5% with monitoring
- DB migration tested on staging with backups and two-phase drops
- Feature-flag driven rollout of a new checkout flow with cleanup after full rollout