[ release-plan:// ] experimental
Features + capacity → release plan: milestones, gates, communication touchpoints, rollback plan. The "we know how this ships" doc.
// system prompt
You generate release plans. User provides: feature list (with rough sizing), release date, capacity. Output: # <Release> — Release Plan Date: <YYYY-MM-DD> Capacity: <available dev-weeks> · Demand: <sum of feature sizes> Headroom: <difference + flag if negative> ## Scope In: • <feature> — <size> Out (deferred): • <feature> — <reason> ## Milestone Schedule WEEK MILESTONE GATE ---- --------- ---- <table — weekly granularity for short releases, biweekly for long> ## Communication Touchpoints • <when> — <audience> — <message> ## Pre-launch Checklist (T-1 week) - [ ] <item> - [ ] <item> ... ## Rollback Plan If <signal> within <window>: <action> Specifically: • <change> → <how to roll it back> ... ## Success Metrics (track for 30 days) • <metric> — baseline: <X>, target post-launch: <Y> • <metric> — <…> ## Monitoring & Alerts • <metric / dashboard> — alert threshold • <…> Rules: - If demand > capacity, output: "OVER CAPACITY by X dev-weeks. Need to cut or extend. See suggested cuts in Out section." - Milestone weeks include INTERNAL gates (design review, security review, beta) + EXTERNAL gates (release, post-launch retro). - Communication touchpoints are calendared — exact week + audience + format. - Pre-launch checklist is concrete (named items, checkable). - Rollback plan must name the rollback procedure per change, not "revert". - Success metrics need baseline + target, not just "improve X".
⚡ powered by Cloudflare Workers AI · quota deducted on success
// output
// sample output
# Customer-Portal Refresh — Release Plan Date: 2026-08-05 Capacity: 72 dev-weeks · Demand: 63 dev-weeks Headroom: +9 dev-weeks (~12% buffer — modest but adequate) ## Scope In: • New onboarding flow — 15 dev-weeks • Settings page redesign — 8 dev-weeks • Bulk-action UI — 12 dev-weeks • Notification center — 10 dev-weeks • Performance pass — 8 dev-weeks • 3 quality-of-life items — 10 dev-weeks Out (deferred): • None at this scope. (If anything emerges mid-release that needs 9+ dev-weeks, the QoL bundle is the natural first cut.) ## Milestone Schedule WEEK MILESTONE GATE ---- --------- ---- W1 All workstreams kicked off; design review locked Design review pass W2 Architecture decisions logged ADR sign-offs W3 First end-to-end build of new onboarding flow Internal dogfood start W4 Settings + Bulk-action UI design final Design freeze W5 Internal beta: onboarding flow Beta gate (10 internal users for 1 week) W6 Notification center first build Internal review W7 Beta gate review; perf pass starts Performance baseline measured W8 External beta opens (~50 customers, opt-in) Customer-beta gate W9 Security review Security gate (must clear before W11) W10 External beta feedback synthesised; bug fixes Bug-burn-down review W11 Final pre-launch testing; CS team training Launch readiness gate W12 LAUNCH (5 Aug) Go/No-Go W13 Post-launch monitoring; daily reviews Stability gate (no rollback) W14 Post-launch retro Lessons-learned doc ## Communication Touchpoints • Weekly (Mon): exec status update. • Bi-weekly (Wed): build team retro + planning. • W1: kickoff comms to Sales + CS + Marketing. • W4: design freeze announcement — design assets handed over. • W7: customer-facing beta announcement (T-5 weeks). • W10: external beta close; CS team brief on incoming changes. • W11: pre-launch all-hands brief (internal); customer T-1-week email. • W12: launch-day comms (in-app banner, email, status page). • W13: post-launch confirmation email to customer base. • W14: retro readout to leadership. ## Pre-launch Checklist (T-1 week) - [ ] All beta feedback resolved or explicitly accepted as known-issue - [ ] Performance baseline confirmed within +5% of pre-release - [ ] CS team trained; FAQ published - [ ] Sales briefed on new affordances for demos - [ ] Status page draft for launch day - [ ] Marketing release notes finalised - [ ] Feature flags configured (in case of partial rollback) - [ ] Monitoring dashboards updated for new features - [ ] Rollback plan rehearsed (table-top exercise) ## Rollback Plan If 5xx rate > 2× baseline OR critical-bug-report count > 10 within 6 hours of launch: roll back. Specifically: • New onboarding flow → behind feature flag `new_onboarding_flow`. Disable via config; old flow returns instantly. • Settings page redesign → behind flag `settings_redesign_v2`. Disable via config. • Bulk-action UI → behind flag `bulk_action_v1`. Disable; affected pages fall back to per-item actions. • Notification center → behind flag `notification_center_v1`. Disable; notifications fall back to email-only. • Performance pass changes → revert to release-1 build (no flag; full rollback). 5-minute window. • Quality-of-life items → individually flag-gated; disable per-item. ## Success Metrics (track for 30 days) • Time-to-First-Value for new signups — baseline: 42 min median, target: ≤ 30 min • Settings-page bounce rate — baseline: 28%, target: ≤ 20% • Bulk-action usage adoption — baseline: 0 (new feature), target: ≥ 15% of weekly actives use it once in first 30 days • Notification opt-in rate — baseline: 0 (new feature), target: ≥ 40% of active users • p95 portal load time — baseline: 1.8s, target: ≤ 1.2s • Support ticket volume — baseline: ~80/week, target: ≤ 80/week (no regression from launch) ## Monitoring & Alerts • `portal_5xx_rate` — alert if > 0.5% sustained 5 min • `portal_p95_latency` — alert if > 1.5s sustained 10 min • `onboarding_completion_rate` — alert if < 60% in any 1h window post-launch • `feature_flag_overrides` — alert if any flag is force-disabled outside the rollback procedure • `support_ticket_inbound` dashboard — daily review for first 30 days
// powered by cloudflare workers ai · quota deducted on success ← back to catalog