Social Launch Results Brief

---
name: ayrshare-social-launch-results-brief
description: Compare a product launch across LinkedIn and X using Ayrshare and native platform history, then return a source-backed results brief and next-post recommendation without publishing.
---

# Social Launch Results Brief

## Loadout capabilities

Use <action-tag>mcp:ayrshare_mcp:get_post_history</action-tag> for posts created through Ayrshare and their provider status. Use <action-tag>mcp:ayrshare_mcp:get_platform_history</action-tag> for native LinkedIn or X posts and available native analytics. These are read-only Actions. Do not publish, retry, reply, or modify content while preparing this brief.

## Outcome

Produce a compact Social Launch Results Brief that shows what shipped, what each platform reports, which content choices appear strongest, what remains incomparable or unavailable, and one evidence-based recommendation for the next post.

## Required inputs

- The campaign name and review window.
- The connected Ayrshare profile and the LinkedIn and X accounts in scope.
- Known Ayrshare post IDs, native post IDs, URLs, or launch timestamps.
- The launch goal and primary success signal.
- Any comparison constraints, such as organic-only results or a fixed observation window.

## Workflow

1. Define the campaign boundary: platforms, accounts, posts, launch time, review cutoff, and primary goal. Do not mix unrelated posts into the result set.
2. Retrieve Ayrshare-originated post history and match records by known ID, URL, timestamp, or exact content. Preserve scheduled, processing, published, deleted, and error states separately.
3. Retrieve native LinkedIn and X platform history for the same accounts and time window with analytics enabled when the connected plan returns them.
4. Join records conservatively. Keep unmatched Ayrshare and native records visible instead of guessing that similar posts are identical.
5. Normalize only directly comparable fields. Record raw counts and observation time. Do not compare rates unless both the numerator and denominator are available from compatible platform definitions.
6. Explain which hook, format, media, timing, or call to action may have contributed to the strongest result. Label this as an inference and cite the exact rows that support it.
7. Recommend one next post with a testable change, target platform, reason, and measurement window. Do not draft or publish it unless separately asked.

## Output contract

- `Campaign boundary`: accounts, platforms, posts, launch window, review cutoff, and goal.
- `Publication status`: Ayrshare ID, native ID, URL, schedule or publish time, and reconciled status per platform.
- `Performance table`: available native metrics with retrieval timestamp and source.
- `Comparison`: comparable findings, non-comparable fields, missing data, and platform-definition differences.
- `Interpretation`: strongest supported observations and clearly labeled hypotheses.
- `Next post`: one bounded test with platform, change, expected signal, and review window.
- `Unknowns`: unmatched records, unavailable analytics, plan limitations, and unresolved provider states.

## Failure and recovery

- If the campaign boundary is unclear, ask for the accounts, posts, and dates before querying broad history.
- If a native ID is unavailable, match by timestamp and exact copy only when the evidence is strong; otherwise leave the record unmatched.
- If platform analytics are absent, report publication status and available counts without inventing reach, clicks, or conversion.
- If metrics use different definitions or observation windows, show them separately and avoid a winner claim.
- If history shows a processing or ambiguous write, surface it as an operational issue rather than treating it as a published result.
- Never publish a recommended follow-up as part of this read-only brief.