# Project Shipper > Manages project launches with readiness checklists, phased rollout plans, cross-team coordination, launch communications, retrospectives, and post-launch monitoring - Skill: `vodouai/project-shipper` (Agent Skill) - Install (CLI): `npx skillmds@latest add vodouai/project-shipper` - Raw SKILL.md: https://api.skillmd.com/api/skills/vodouai/project-shipper/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: VodouAI (https://skillmd.com/u/vodouai) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/vodouai/project-shipper --- # Project Shipper Agent ## Overview This agent handles everything involved in shipping a project: building launch checklists, planning phased rollouts, coordinating across teams, running the launch itself, monitoring post-launch, and running retrospectives. Use it when you are preparing to ship anything -- a new feature, a major release, a migration, an infrastructure change, or an internal tool rollout. The agent is opinionated about one thing: every launch needs a plan. The plan can be lightweight for small changes, but it must exist. **STOPPING POINT 1**: Where are you in the shipping process? 1. **Build a launch checklist** - Create a comprehensive readiness checklist for an upcoming launch 2. **Plan a phased rollout** - Design a staged release with gates between phases 3. **Coordinate cross-team launch** - Organize activities across multiple teams for a coordinated launch 4. **Run a launch day** - Execute the launch plan and handle real-time decisions 5. **Set up post-launch monitoring** - Define what to watch after launch and for how long 6. **Run a launch retrospective** - Review how the launch went and capture improvements --- ## Workflow 1: Build a Launch Checklist ### Determine launch tier Not every launch needs the same level of ceremony. Classify first: | Tier | Scope | Examples | Planning needed | |------|-------|---------|-----------------| | **Tier 1: Major** | User-facing, high visibility, hard to reverse | New product, pricing change, platform migration | Full checklist, phased rollout, war room | | **Tier 2: Standard** | User-facing, moderate scope, reversible | New feature, significant UI change, API update | Standard checklist, staged rollout | | **Tier 3: Minor** | Small scope, easily reversible | Bug fix, copy change, config update, small feature | Abbreviated checklist, direct deploy | ### Full launch readiness checklist ``` LAUNCH READINESS CHECKLIST Project: [name] Target launch date: [date] Launch tier: [1 / 2 / 3] Launch owner: [person] PRODUCT READINESS - [ ] All acceptance criteria met and verified - [ ] Edge cases identified and handled (or documented as known limitations) - [ ] Error states have clear user-facing messages - [ ] Loading states and empty states are implemented - [ ] Accessibility requirements met (keyboard nav, screen reader, contrast) - [ ] Mobile/responsive behavior verified (if applicable) - [ ] Internationalization handled (if applicable) TECHNICAL READINESS - [ ] Code reviewed and merged to release branch - [ ] All automated tests passing (unit, integration, e2e) - [ ] Manual QA completed -- test plan documented with results - [ ] Performance testing done -- latency and throughput within targets - [ ] Database migrations tested (if applicable) - [ ] Feature flags configured for rollout control - [ ] Rollback plan documented and tested - [ ] Monitoring and alerting set up for new endpoints/features - [ ] Logging sufficient to debug issues post-launch - [ ] Load testing done if expecting traffic spike OPERATIONAL READINESS - [ ] On-call team briefed on what is launching and how to respond to issues - [ ] Runbook created for common failure scenarios - [ ] Support team trained on new feature (FAQs, known issues, escalation path) - [ ] Documentation updated (help center, API docs, internal wiki) COMMUNICATION READINESS - [ ] Internal announcement prepared (who needs to know inside the company) - [ ] External announcement prepared (changelog, blog post, email, social) - [ ] Customer-facing documentation published - [ ] Sales/marketing briefed (if applicable) LEGAL/COMPLIANCE - [ ] Privacy review completed (if collecting new data) - [ ] Terms of service updated (if applicable) - [ ] Compliance requirements met (if applicable) GO/NO-GO - [ ] Launch owner has reviewed all items above - [ ] Stakeholders have signed off - [ ] Launch date and time confirmed - [ ] Rollout plan confirmed ``` **STOPPING POINT 2**: Checklist is prepared. What do you need? 1. **Identify gaps** - Review the checklist to find items that are not yet complete and plan to close them 2. **Build the rollout plan** - Design the phased rollout strategy 3. **Prepare communications** - Draft internal and external launch communications 4. **Schedule the launch** - Set the date, time, and assign responsibilities 5. **Create the rollback plan** - Document exactly how to undo the launch if something goes wrong --- ## Workflow 2: Plan a Phased Rollout ### Rollout strategies Choose based on risk tolerance and infrastructure: **Feature flag rollout** (most common for SaaS): ``` Phase 1: Internal team only (dogfooding) -- 1-3 days Gate: No critical bugs, team feedback addressed Phase 2: 5% of users (random sample) -- 3-5 days Gate: Error rate stable, key metrics not degraded, no P0 support tickets Phase 3: 25% of users -- 3-5 days Gate: Same as Phase 2 plus performance metrics stable Phase 4: 50% of users -- 2-3 days Gate: Same as Phase 3 Phase 5: 100% of users Gate: 48 hours of monitoring at 50% with no issues ``` **Canary release** (for infrastructure/backend changes): ``` Phase 1: Single canary instance (1% of traffic) -- 1-2 hours Gate: No errors, latency within bounds, no anomalies in logs Phase 2: One availability zone (10-25% of traffic) -- 4-24 hours Gate: Metrics match control, no degradation Phase 3: All zones (100% of traffic) Gate: 1 hour of monitoring at partial rollout with no issues ``` **Geographic rollout** (for major product changes): ``` Phase 1: Smallest market (e.g., single country) -- 1-2 weeks Gate: Metrics meet targets, localization issues resolved Phase 2: Secondary markets -- 1-2 weeks Gate: Consistent results across Phase 1 and 2 Phase 3: Primary markets Gate: All issues from earlier phases resolved ``` ### Rollout plan template ``` ROLLOUT PLAN: [project name] Strategy: [feature flag / canary / geographic / other] Start date: [date] Estimated full rollout: [date] PHASE 1: [description] Audience: [who sees this] Duration: [time] Success criteria: - [metric] within [threshold] - [metric] within [threshold] Gate approval: [who decides to proceed] Rollback trigger: [specific conditions that cause immediate rollback] PHASE 2: [description] ... ROLLBACK PLAN: How to rollback: [exact steps -- feature flag off, deploy previous version, etc.] Time to rollback: [how long it takes -- should be < 15 minutes for Tier 1] Data considerations: [any data created during rollout that needs handling on rollback] Who can trigger: [who has authority to rollback without additional approval] ``` --- ## Workflow 3: Coordinate Cross-Team Launch ### RACI for launch activities ``` LAUNCH RACI: [project name] Activity | Responsible | Accountable | Consulted | Informed ----------------------------|-------------|-------------|-----------|---------- Feature implementation | [eng team] | [eng lead] | [product] | [design] QA and testing | [QA] | [eng lead] | [eng] | [product] Rollout execution | [eng] | [eng lead] | [ops] | [all] Monitoring post-launch | [eng + ops] | [eng lead] | [support] | [product] Support training | [support] | [support mgr]| [product]| [eng] Documentation | [docs team] | [product] | [eng] | [support] External communication | [marketing] | [product] | [exec] | [all] Customer notification | [success] | [product] | [support] | [exec] Rollback decision | [eng lead] | [product] | [exec] | [all] ``` ### Launch timeline ``` LAUNCH TIMELINE: [project name] T-14 days: - [ ] Feature complete and in QA - [ ] Support training materials drafted - [ ] Documentation in review T-7 days: - [ ] QA signed off - [ ] Support training completed - [ ] Documentation published (hidden or behind flag) - [ ] Internal announcement sent - [ ] External comms drafted and approved T-2 days: - [ ] Go/no-go meeting with all stakeholders - [ ] Rollout plan confirmed - [ ] On-call team briefed - [ ] Monitoring dashboards verified T-0 (launch day): - [ ] Execute rollout per plan - [ ] Monitor dashboards - [ ] Support team on alert for incoming tickets - [ ] External comms published on schedule T+1 day: - [ ] Review first 24 hours of metrics and support tickets - [ ] Address any urgent issues - [ ] Proceed to next rollout phase or hold T+7 days: - [ ] Full metrics review - [ ] Support ticket analysis - [ ] Decision on remaining rollout phases T+14 days: - [ ] Launch retrospective - [ ] Final metrics report - [ ] Learnings documented ``` **STOPPING POINT 3**: Cross-team plan is in place. What is needed? 1. **Run the go/no-go meeting** - Facilitate the final decision meeting before launch 2. **Draft the communications** - Write the internal and external launch messages 3. **Build the monitoring dashboard** - Define what metrics to watch on launch day 4. **Prepare the war room** - Set up the real-time coordination plan for launch day 5. **Create the runbook** - Document step-by-step procedures for common launch day scenarios --- ## Workflow 4: Post-Launch Monitoring ### Monitoring framework ``` POST-LAUNCH MONITORING PLAN: [project name] Monitoring period: [typically 2 weeks for Tier 1, 1 week for Tier 2] REAL-TIME METRICS (check every 15-30 min on launch day, then hourly): - Error rate: [baseline] -- alert if > [threshold] - Latency (p50, p95, p99): [baselines] -- alert if > [thresholds] - Availability/uptime: [baseline] -- alert if < [threshold] DAILY METRICS (check every 24 hours): - Feature adoption rate: [expected vs actual] - Key conversion metrics: [list with baselines] - Support ticket volume: [expected vs actual] - User sentiment (if measurable): [NPS, satisfaction scores] WEEKLY METRICS (check at end of each week): - Retention impact: [any change in retention for users exposed to new feature] - Revenue impact: [if applicable] - Performance trends: [are metrics stable or drifting] ESCALATION CRITERIA: - Immediate rollback: [specific conditions, e.g., error rate > 5%, data loss detected] - Team alert: [conditions that require investigation but not rollback] - Stakeholder notification: [conditions that leadership needs to know about] ``` ### Post-launch report At the end of the monitoring period: ``` POST-LAUNCH REPORT: [project name] Launch date: [date] Full rollout date: [date] Report date: [date] LAUNCH OUTCOME: [successful / successful with issues / partial rollback / full rollback] METRICS SUMMARY: - [Metric]: Expected [X], Actual [Y] -- [met/missed/exceeded] - [Metric]: Expected [X], Actual [Y] -- [met/missed/exceeded] ISSUES ENCOUNTERED: 1. [Issue]: [Severity] -- [Resolved/Ongoing] -- [Resolution/Plan] SUPPORT IMPACT: - New tickets related to launch: [count] - Common themes: [list] - Knowledge base gaps identified: [list] ADOPTION: - Users exposed: [count] - Feature adoption rate: [percentage] - Usage patterns: [notable observations] STATUS: [Monitoring complete, feature stable / Ongoing monitoring required] ``` --- ## Workflow 5: Launch Retrospective ### Retrospective format (60 min) Run within 1-2 weeks of full rollout. **Preparation** (send to participants 24 hours before): - Review the launch timeline: what happened when - Bring specific examples, not just feelings - Think about: What would you do differently if you could rerun this launch? **Session structure:** ``` LAUNCH RETROSPECTIVE: [project name] Date: [date] Participants: [list] TIMELINE REVIEW (10 min) Walk through what actually happened vs what was planned. WHAT WENT WELL (15 min) [Each participant shares 1-2 things. Capture specifics, not generalities.] 1. [Specific thing] - Why it worked: [reason] 2. [Specific thing] - Why it worked: [reason] WHAT COULD HAVE GONE BETTER (15 min) [Same format. Focus on process, not blame.] 1. [Specific thing] - What would have improved it: [suggestion] 2. [Specific thing] - What would have improved it: [suggestion] SURPRISES (10 min) [Things no one anticipated] 1. [What happened] - How we handled it: [response] ACTION ITEMS (10 min) [Concrete changes to make for the next launch] 1. [Action] - Owner: [who] - Due: [when] 2. [Action] - Owner: [who] - Due: [when] ``` **STOPPING POINT 4**: Retrospective is complete. What should happen next? 1. **Update the launch checklist template** - Incorporate learnings into the standard checklist 2. **File process improvements** - Create tickets for the action items identified 3. **Share learnings broadly** - Write up key takeaways for other teams 4. **Plan the next launch** - Apply learnings to an upcoming launch 5. **Archive launch artifacts** - Organize all launch documents for future reference