go-live-readiness

name	go-live-readiness
description	This skill should be used when an Orderful customer is approaching their cutover date and the Implementation team needs to verify they're actually ready to flip to LIVE. Triggers on: "go-live readiness for [customer]", "pre-cutover check for [customer]", "is [customer] ready to go live", "run the cutover checklist", "what's blocking [customer] go-live", "ready to cutover [customer]". Produces a structured readiness report with a checklist of pre-cutover requirements, a risk assessment, and a cutover sequence plan.
version	0.1.0

Go-Live Readiness

The customer's cutover date is approaching. Before anyone flips a switch, run the readiness check.

When this fires

The migration plan has been worked. Most partnerships are LIVE or one step away. The customer is asking about cutover or the AM is preparing for the cutover call. There's a date on the calendar.

Inputs to gather

Run all of these in parallel:

• Onboarding profile — <customer-slug>-onboarding-profile.md for the original go-live target and contract commitments.
• Migration plan — <customer-slug>-migration-plan.xlsx for what was supposed to be live.
• Live partnership state from Orderful — call list_relationships for the customer's org. Group by status: LIVE, READY, SETUP, blocked.
• Open Intercom tickets — search for any open RnD Outreach tickets for this customer. Any open ticket on a Tier 1 partner is a cutover blocker.
• Recent transaction activity — call list_transactions for the customer's org for the last 30 days. Surface: total volume, validation error rate, delivery failure rate.
• Communication channels — call list_communication_channels for the org. Verify production channels are configured and tested (not just sandbox).
• Scenarios — call list_scenarios for each major partnership. Verify scenarios are published, not draft.
• Billing — call get_billing_summary for the org. Verify billing customer is configured and the contract terms match.

Step 1 — Run the checklist

Score each item: ✅ Pass, ⚠️ Warning, ❌ Blocker, ❓ Unknown.

Network readiness

• All Tier 1 partnerships in LIVE state
• All Tier 2 partnerships in LIVE or READY state
• No partnerships stuck in SETUP for more than 7 days
• No partnerships with open Intercom tickets blocking testing

Configuration readiness

• Production communication channel(s) configured
• All scenarios published, none in draft
• ISA IDs match what was sent to partners
• Guideline sets versioned and published
• No relationship using elevated-permission overrides without a clear reason

Volume & error readiness

• Test transactions flowing in last 7 days
• Validation error rate below 5% on Tier 1 partnerships
• Delivery failure rate below 1% on Tier 1 partnerships
• No overdue functional acknowledgments

Operational readiness

• Billing customer configured
• Customer contacts have user accounts in Orderful
• Customer has been trained on the dashboard (check Confluence or ticket history)
• AE handoff promises all addressed (or explicitly accepted as out-of-scope)
• CS contact identified for post-go-live handover

Step 2 — Build the report

Save as <customer-slug>-go-live-readiness.md in the workspace (or .pdf via the pdf skill if the user prefers).

Structure:

1. Verdict — one line at the top: "Ready to cut over on " / "Cutover NOT recommended — N blockers" / "Cutover possible with caveats — N warnings". This is what the AM reads first.

2. Blockers — the ❌ items. For each: what it is, why it blocks cutover, and the specific next action to clear it. If empty, write "No blockers identified."

3. Warnings — the ⚠️ items. Each with: what it is, the risk if we cut over anyway, mitigation.

4. Checklist results — the full table from Step 1 with status icons. AM can scan this.

5. Cutover sequence — if the verdict is Ready or Ready-with-caveats, propose the actual cutover steps in order. Example: T-3 days notify partners, T-1 day final test transaction, T-0 morning flip comm channels, T-0 afternoon monitor volume, T+1 day confirm reconciliation. Sequence should be customer-specific based on what's actually in scope.

6. Post-cutover monitoring plan — what to watch in the first 48 hours: which partners' volume to track, error thresholds that trigger rollback, who's on call.

Rules

• Blockers are blockers. Don't soften "❌ Blocker" into "consider addressing". If a Tier 1 partner is in SETUP state and we're 3 days from cutover, that IS a blocker. Say so.
• Don't run a partial check. If any of the inputs fail to load, say which one and stop. Half a readiness check is worse than none.
• Cross-check the date. If the migration plan target was Feb 1 and the user is asking about cutover for Jan 20, surface that discrepancy explicitly.
• Be specific in "next action". Not "talk to the partner" — say "Reply to Intercom ticket #12345 with the missing 856 scenario steps." Concrete, actionable.
• No rubber stamps. If everything passes, say so confidently — but require the AM to acknowledge they've reviewed the post-cutover monitoring plan before declaring Ready.

After saving, output a 4-line summary in chat: verdict, blocker count, warning count, link to the report. If Ready: suggest the AM schedules the cutover. If Blocked: suggest specific next actions and a follow-up date for re-running this skill.