Approved Product Launch

---
name: ayrshare-approved-product-launch
description: Turn one approved product update into channel-specific LinkedIn and X posts, obtain exact approval, publish once through Ayrshare, and return a reconciled launch receipt.
---

# Approved Product Launch

## Loadout capabilities

Use <action-tag>mcp:ayrshare_mcp:validate_media</action-tag> when the approved launch includes media. Use <action-tag>mcp:ayrshare_mcp:validate_post</action-tag> as the dry-run check for each final platform payload. Neither validation Action publishes content.

Only after the user approves the exact profiles, copy, links, media, and timing, use <action-tag>mcp:ayrshare_mcp:create_post</action-tag> once per distinct approved payload with a stable idempotency key. Preserve every per-platform result. Use <action-tag>mcp:ayrshare_mcp:get_post_history</action-tag> to reconcile terminal state. If Ayrshare returns a structured error, use <action-tag>mcp:ayrshare_mcp:explain_error</action-tag>. Use <action-tag>mcp:ayrshare_mcp:retry_post</action-tag> only for a confirmed failed post that Ayrshare marks eligible for its one bounded retry. Never repeat `create_post` to recover a partial failure.

## Outcome

Produce and execute one reviewable product-launch packet for LinkedIn and X. The finished result includes channel-specific content, an exact approval record, a per-platform launch receipt, unresolved errors, and the next follow-up checkpoint.

## Required inputs

- The final approved release page or source brief.
- The claims, links, media, and calls to action that may be used.
- The selected company or founder profiles and the connected Ayrshare profile that owns them.
- The desired LinkedIn and X formats, such as a single post or X thread.
- The publish window, time zone, and whether to publish immediately or schedule.
- Any forbidden claims, required disclosures, or partner-review constraints.

## Workflow

1. Read the approved source and make a fact table with the release claim, supporting source, audience value, link, media, and any limitation. Do not add unapproved performance claims or customer names.
2. Confirm the target Ayrshare profile and verify that LinkedIn and X are connected. If account ownership or plan entitlement is unclear, stop before preparing a write.
3. Draft LinkedIn and X separately. The LinkedIn version should explain the work outcome and why it matters. The X version should make one concise claim or a coherent thread. Keep the facts consistent without copying one channel verbatim into the other.
4. Assemble the launch packet with the exact platform, profile, final text, links, media, accessibility text, format options, schedule, and stable idempotency key for each payload.
5. Validate every media item, then dry-run each final post. Resolve length, format, media, account, or scheduling errors without publishing.
6. Show one compact approval table. Ask the user to approve the exact bounded launch packet. Editing a field after approval invalidates the approval for that payload.
7. After exact approval, call `create_post` once for each distinct approved payload. Record the top-level Ayrshare post ID and every platform result without collapsing partial success into one status.
8. Reconcile each post through history until it is published, scheduled, or terminally failed. Explain provider errors. Retry only a confirmed eligible failed post, never a successful or ambiguous one.
9. Return the launch receipt and schedule a results review window without publishing any follow-up content.

## Output contract

- `Approved source`: release title, source URL, approved claims, approved media, and constraints.
- `Launch packet`: one row per payload with profile, platform, final copy, links, media, format options, UTC schedule, and idempotency key.
- `Validation`: media and post checks, warnings, and all changes made before approval.
- `Approval`: who approved, when, and the exact payload fields covered.
- `Launch receipt`: Ayrshare post ID plus separate LinkedIn and X status, native ID, URL, and error.
- `Recovery`: reconciled state, error explanation, retry eligibility, and any remaining human action.
- `Next checkpoint`: when to review available performance signals.

## Failure and recovery

- If the source is not approved or facts conflict, stop and request a single approved source of truth.
- If the target profile or social connection is uncertain, do not publish.
- If validation fails, revise the draft and validate again. Validation never substitutes for approval.
- If a call returns partial success, preserve the successful platform result and reconcile the failed one. Do not call `create_post` again.
- If a write times out or returns an ambiguous result, inspect history using the idempotency key and known post identifiers before considering recovery.
- If a post is terminally failed, explain the error and ask before the single provider-supported retry.
- Never delete, reply, message, or publish a follow-up unless the user separately requests and approves it.