Pwp deploy
11 systematic skills for Claude Code — structured protocols for debugging, code review, security, refactoring, testing, deployment, and more. No vibes, just discipline.
npx -y skills add shandar/pwp-plugin --skill pwp-deployAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 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.
What its author says it does
Copied from the file, not written here
Deployment protocol — safe, observable, reversible releases from main to production. Use this skill whenever the user is deploying, releasing, shipping, or pushing to production. Also use when they say 'deploy this', 'ship it', 'push to production', 'release', 'go live', 'pre-deploy check', 'rollback', 'feature flags', or ask about deployment strategies, staging, CI/CD pipelines, or monitoring setup. Covers environment ladder, pre-deploy checklist, deployment strategies, database migration safety, feature flags, rollback plans, and post-deploy verification.
SKILL.md
5.5 KB, as published. Nobody here has run it
PWP 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