Execute Linkedin Outreach

Execute Flywheel LinkedIn Outreach

Use Flywheel MCP as the source of truth for Action state, ownership, recipient, proposed content, schedule, and campaign context. In conversation, a user may call an Outreach Action a "task." In tools and persisted state, always use Outreach Action or Action.

LinkedIn only

Process only these Action types:

• linkedin_connect
• linkedin_message
• linkedin_inmail
• linkedin_engage

Never list, inspect for execution, send, cancel, or reopen an email Action. If the user asks for email work, explain that this skill handles LinkedIn only.

Current user only

This skill is shared across users. The MCP Action tools are scoped to the connector's authenticated user. Never attempt to inspect or act on another teammate's queue. Before every touch, verify from get_outreach_action that the Action is still assigned to the authenticated user. If ownership is wrong or ambiguous, stop and report a systemic authorization problem.

Load the queue

Call list_outreach_actions with:

{
  "action_types": [
    "linkedin_connect",
    "linkedin_message",
    "linkedin_inmail",
    "linkedin_engage"
  ],
  "statuses": ["proposed"],
  "limit": 50
}

Add campaign_id or account_domain only when the user narrows the request. Follow next_cursor until it is null when the user asks to process the whole queue. Do not act on a future scheduled_for time.

Inspect before acting

Before every external touch:

1. Call get_outreach_action with the Action id.
2. Confirm its type is one of the four LinkedIn types above.
3. Confirm its status is proposed, its schedule is due, and it belongs to the authenticated user.
4. Verify the intended LinkedIn profile, person, account, campaign, rationale, and proposed content.
5. If the profile identity or requested touch is ambiguous, stop instead of guessing.

Treat not found as inaccessible, reassigned, or stale. Never work around that boundary.

Perform the touch

Flywheel records the Action but does not perform LinkedIn outreach. Use the client's authenticated, interactive browser session. In Codex, prefer the user's signed-in Chrome integration. In Claude, use Claude for Chrome or the authenticated Cowork browser. Do not use a headless LinkedIn API.

If the browser integration, LinkedIn session, correct profile, or required capability is unavailable, report the blocker and leave the Action unchanged.

Perform exactly the requested touch:

• linkedin_connect: send the connection request. Add no note unless the Action explicitly includes one.
• linkedin_message: send the proposed message to the verified profile. Do not invent copy.
• linkedin_inmail: send the proposed InMail only when the account has the required credit and the recipient matches.
• linkedin_engage: perform only the exact like, comment, follow, or other engagement described by the Action.

Respect LinkedIn warnings and limits. Never bypass restrictions, connection limits, missing InMail credits, or anti-abuse controls.

Record lifecycle state

Call update_outreach_action with status: "sent" only after the LinkedIn UI visibly confirms the touch succeeded. The state update records the outcome; it does not perform or prove the touch.

Use status: "canceled" only when the proposed touch should not happen. Supply the most accurate supported cancel_reason and a concise factual cancel_note when useful. A browser failure, temporary session problem, or unavailable integration is not a cancellation reason; leave the Action proposed and report the blocker.

Use status: "proposed" to reopen canceled work only when the user explicitly asks.

Report directly observed replies

When the requested browser work directly reveals a response associated with the Action, record the observed fact with report_campaign_signal:

• connection accepted: channel: "linkedin", activity_type: "connection_accepted"
• LinkedIn message received: channel: "linkedin", activity_type: "message_received"

Pass campaign_id and action_id, the observed occurred_at when known, a stable idempotency_key, and an optional factual note. Do not infer interest, score the response, or report acceptance without direct evidence. Do not scan unrelated historical Actions unless the user asks.

Report the result

Summarize:

• Actions sent;
• Actions canceled and why;
• Actions skipped;
• blockers requiring user action.

Lead with the person and account names. Include Action ids for traceability.