Skill: Analyze LinkedIn messages to capture your writing voice

---
name: analyze-linkedin-messages
description: Analyze the user's real LinkedIn messages to produce a writing voice profile, a library of conversation opener templates ranked by reply rate, a library of reply and follow-up templates ranked by continuation rate, or any combination. Use when the user asks to capture or learn their LinkedIn writing style or tone of voice, build refresh or review their message templates, understand what their outreach or follow-up looks like, or find out which openers, replies, or nudges actually work. Does not draft messages, it produces the files a drafting skill reads. Requires the Groovin connector.
---

# Analyze LinkedIn messages

<!-- Groovin skill | version 2026-10-12 | https://groovin.mintlify.app/mcp/skills -->

One scan of the user's LinkedIn conversations, two possible outputs:

- **Voice profile**: how this person actually writes. Feeds any drafting skill, on LinkedIn or elsewhere.
- **Template library**: `linkedin_msg_templates.md`, opener skeletons ranked by reply rate, plus a reply and follow-up section ranked by continuation rate.

This skill does not draft messages. It produces the files a drafting skill reads. The companion skill is `draft-linkedin-message`, but do not assume it is installed.

The scan is the slow part and it is shared. Never run it twice in the same session.

---

## Before you start

**Groovin must be connected.** The scan uses the Groovin tools `list_linkedin_conversation_attendees`, `get_linkedin_chat_messages` and `list_linkedin_pending_invitations`. If they are not available, say so and stop: there is nothing to analyze without them.

**Work out what your environment gives you, once, and adapt.** Do not ask the user about it.

| If you have | Then |
|---|---|
| A working folder you can read and write | Save the scan cache and the output files there. |
| No folder (a plain chat) | Skip the cache. Deliver the output files as downloadable files or documents, and tell the user to keep them: project knowledge, a notes tool, anywhere they can hand them back later. |
| A tool for asking the user structured questions | Use it wherever this skill says "ask". |
| No such tool | Ask in plain text, one topic at a time, and wait for the answer. |

Nothing in this skill sends a LinkedIn message, changes the inbox, or writes to the CRM. Say so if the user asks.

---

## Reading speed

- `list_linkedin_conversation_attendees` and `get_linkedin_chat_messages` carry no LinkedIn limit. Read conversations one after another, no pauses needed.
- If one of them returns a 429 or a 5xx, wait briefly and retry once. If it fails again, stop, save what you have, and tell the user to resume later.
- `list_linkedin_pending_invitations` is a live LinkedIn read. One call per run, never more.
- Never call `get_linkedin_profile`. Extraction does not need it and it is the most limited read LinkedIn allows.

### Time estimate

One call per conversation. 100 conversations usually takes a few minutes; long threads take longer to read than short ones. Give the user a rough figure ("a few minutes"), not a precise one.

---

## Step 1: What are we producing

Ask three things before touching the API.

**Outputs.** Voice profile only, templates only, or both. Say what each one is for in a line, no more. The template output covers both how you open conversations and how you reply and follow up, say that in the one-liner.

**Existing voice profile.** Only if voice is selected. Look for an existing writing style file wherever your environment keeps the user's files: the working folder, project files, or the instructions file (`CLAUDE.md`, project instructions, custom instructions) if it points at one. Common names include `writing-style.md`, `my-writing-style.md`, `voice.md`, `linkedin-writing-voice.md`. If you cannot look, ask whether they have one and to paste it.

If you find one, show the user what is in it and ask what to do:

- add a LinkedIn section to it, keeping the rest untouched
- write a separate LinkedIn-only file and leave the existing one alone
- leave it alone entirely and skip the voice output

If you find nothing, say so and continue. Write a LinkedIn-only file at the end.

**Existing templates.** Only if templates are selected. Look for `linkedin_msg_templates.md` the same way. If it exists, do not rebuild silently. Show what is in it and ask whether to refresh, add to it, or leave it alone. This applies to the whole file, openers and reply/follow-up sections together, unless the user says to touch only one.

**AI drafting.** Only if voice is selected. Ask plainly: do they use an AI tool to write LinkedIn messages, and roughly since when. If yes, note the date. Messages after it are suspect, and the flagging pass in Step 6 gets stricter. This matters because a profile built on AI-drafted messages captures the AI's voice and then locks it in permanently.

## Step 2: Cache check

Only when you have a working folder. Otherwise skip to Step 3.

Look for `.linkedin_scan.json` in the working folder.

If it exists and covers the requested depth, reuse it. Say so: "I already have 100 conversations from 12 March. I can build the voice profile from those without reading LinkedIn again, or rescan for fresher data."

Older than about 6 weeks, mention the age and recommend a rescan.

If it covers fewer conversations than requested, fetch only the gap.

If an older cache has no `preceding_message` field (see Step 5), treat it as missing reply/follow-up data even though openers and voice are fine. Say so and offer to fetch just those conversations again rather than a full rescan.

## Step 3: Scope

Call `list_linkedin_conversation_attendees` once with `limit: 300`. This returns the 300 most recent conversations, most recent first, with their conversation details. Do not fetch the whole inbox: a large one is thousands of people.

Clean the list before anything else:

- Keep attendees that have a `conversation_id`.
- Drop `conversation_type: "SPONSORED"`. Those are ads, not conversations.
- Note `conversation_type: "INMAIL"`. InMail is its own format (see Step 5).
- **De-duplicate by `conversation_id`.** A group chat appears once per member. Keep one entry and mark it `is_group: true`.

**Audience focus.** Summarize the headline and occupation spread, then ask whether to analyze everyone or focus on one audience. Filtering on `headline` costs nothing and gives a cleaner sample. Describe the groups in the user's own world, whatever it is: "Most of your recent conversations are with founders (41), investors (28), and candidates (12). Analyze all, or focus on one?"

If the user picks one audience and the 300 do not hold enough of it, say so and offer to call again with a higher `limit`.

**Depth.** Default is the latest 100 conversations. Offer a faster 30.

Note if asked: voice stabilizes around 40 to 60 substantive messages, which 30 conversations usually clears. Reply-rate and continuation-rate comparison between clusters needs 100 or it is ranking noise. So templates-only and both should lean 100, voice-only can go either way.

## Step 4: Confirm before launching

Do not start fetching until the user has confirmed. State plainly:

- how many conversations
- the rough time
- whether progress is saved as you go (only with a working folder)
- what will be written at the end

Example:

> 100 conversations, a few minutes. I only read: nothing is sent and nothing changes in your inbox or CRM. At the end you get a voice profile and a template library covering openers, replies, and follow-ups. Go ahead?

Wait for a yes.

## Step 5: Fetch

### Pending invitations

One call, `list_linkedin_pending_invitations`:

~~~
direction:    "sent"
sent_after:   {start of the conversation sample's date range}
sent_before:  {today}
limit:        100
~~~

These are invites the user sent that have not been accepted. Each carries the invitation `message`, `headline`, and `sent_at`.

Do not narrow `sent_before` at the API. Fetch everything back to the start of the sample and apply the 7 day cutoff locally when computing ignored counts. An invite still pending after a week is very unlikely to be accepted; anything more recent tells you nothing because the person may not have looked yet. But the notes themselves are user-written text and belong in the voice corpus regardless of age.

Skip invites sent with no note.

The response reports `total_matched` and `truncated`. Remember whether it was truncated.

### Conversations

With a working folder: write `.linkedin_scan.json` and append after every single conversation, so an interruption loses nothing. On a re-run, read it first and skip what is already there. Tell the user once that this file holds their raw messages and the names of the people they talk to: it stays on their machine and should not be shared or committed anywhere.

Without a folder: keep the records in the conversation. Say that a later session will have to scan again.

For each conversation, `get_linkedin_chat_messages` with `limit: 100`.

Sort the returned page by timestamp ascending. Do not assume the API returns oldest first. Ignore messages flagged as deleted.

Record per conversation:

~~~
conversation_id, name, headline, occupation, network_distance,
conversation_type, is_group,
has_cursor, total_messages,
first_message_text, first_message_type, first_message_sent_by_me,
first_message_at, got_reply, reply_latency_hours,
my_messages: [ {text, message_type, position, sent_at, language, preceding_message} ]
~~~

`my_messages` is every message with `sent_by_me: true`, not just the first. This is the voice corpus and it is already in the response. `position` is 1 for the conversation's first message and 2+ for anything after it.

`language` is the language the message is written in. Many people write LinkedIn messages in two languages; Step 6 needs to keep them apart.

`preceding_message` is the single message immediately before this one in the full thread, taken from the same page you already fetched: `{text, sent_by_me, sent_at}`, or `null` if this message is the conversation's first (position 1). It costs no extra call. It is what lets Step 7 tell a reply apart from a nudge:

- `preceding_message.sent_by_me` is `false`: this message replies to something they said. Their text is the trigger.
- `preceding_message.sent_by_me` is `true`: this message follows up on your own message that got no reply in between. A nudge.

`got_reply` is true when any message after the user's first has `sent_by_me: false`.

**Format.** Every opener has one of three formats, and they must never be clustered together:

- `invite_note`: when a connection request is accepted, the invitation note appears as the first message. Use `message_type` to tell it apart from a normal message. Capped at 300 characters.
- `inmail`: `conversation_type` is `INMAIL`. Sent to someone outside the user's network, usually with a subject line.
- `dm`: everything else.

**Group chats.** If `is_group` is true, or the thread has more than one other sender, keep `my_messages` for the voice corpus and exclude the conversation from all template statistics. A reply in a group is not a reply to an opener.

**Conversations returning a cursor.** A thread over 100 messages is a relationship, not templated outreach. Do not page it, and exclude it from template clustering, openers or replies alike. But keep its `my_messages` for the voice corpus. Long threads are the richest voice material in the sample.

Progress: one line per 20 conversations, not per conversation.

**Do not delete `.linkedin_scan.json` at the end.** It is what makes a later run instant.

---

## Step 6: Voice extraction

Skip if voice was not selected.

### Corpus

Every `my_messages` entry from every conversation including cursor ones and group chats, plus every pending invite note.

Drop before analyzing: quoted text, signature blocks, bare links, and one-word acknowledgements ("thanks", "sure", "ok", "great", and their equivalents in other languages). They inflate the count without adding signal. Report the real number: "312 messages, 247 substantive."

Under 15 substantive messages, stop. Say so and offer to widen. Do not build a profile from a handful of examples.

### Languages

Count substantive messages per language and say what you found: "212 in English, 96 in German."

- A language with 15 or more substantive messages gets its own rule set. Extract it separately. Do not blend languages: greetings, length, punctuation and formality differ.
- A language under 15 is listed under Low confidence with whatever is observable, and no rules.
- Where the language has a formal and an informal address (du/Sie, tu/vous, tú/usted), record which one the user uses, with whom, and with counts. This is the rule a drafting skill most needs and most often gets wrong.
- Note what decides the language, if the sample shows it: the other person's language, their country, who wrote first.

A single-language corpus skips all of this silently.

### Contamination flagging

Before extracting anything, look for messages that were probably not written by the user.

Tells, in rough order of reliability:

- near-identical structure repeated across many messages that are not obviously a deliberate template
- punctuation and capitalisation noticeably cleaner than the surrounding corpus
- em dashes clustered in a subset while absent everywhere else
- sudden uniformity in length after a date
- sent in tight bursts at machine speed

If the user named a date in Step 1, weight anything after it more heavily.

Show the flagged set, grouped, with counts. Let the user exclude before the profile is written. Do not exclude anything silently.

### Marking

Every rule is labelled with where it holds:

- `opener` (position 1 DMs)
- `reply` (position 2+)
- `invite_note` (capped at 300 characters, always cold)
- `inmail` (only if the sample has enough of them)

A rule holding in more than one bucket is stronger than one holding in a single bucket. Say which.

This matters most for length and structure. An invite note is constrained to 300 characters, so any length rule derived from it is wrong applied to a DM. Never let invite note rules leak into DM guidance.

### What to extract

- **Mechanics**: length distribution, greeting forms, sign-offs, capitalisation, punctuation (including whether they actually use em dashes), emoji, contractions, link habits, line breaks and paragraphing.
- **Structure**: how they open, how they make an ask, how they close, whether they front-load or bury the point.
- **Lexicon**: recurring phrases, filler they do use, words and constructions they never use.
- **Register shifts**: differences by `network_distance` or audience, but only if the sample actually supports it. Do not invent a split from four messages.

Every rule carries the count supporting it. Absolute numbers, never a bare percentage.

### Preserving voice

Document how this person writes, do not improve it. Lowercase stays lowercase. Missing punctuation stays missing. Blunt stays blunt. Typos they repeat are a habit, not an error. Do not add em dashes and do not add "I hope this finds you well."

If the profile reads like advice, it is wrong. It is a description.

## Step 7: Template extraction

Skip if templates were not selected.

This step covers two different things: how the user opens conversations, and how they reply or follow up once one is underway. They get different treatment because they answer different questions and use different metrics. Do not blend them into one comparison.

### Openers

Keep conversations where the earliest message has `sent_by_me: true`, `has_cursor` is false and `is_group` is false.

Report the yield plainly: "58 of 100 were started by you."

Under 15 usable, say so and offer to widen the sample. Do not invent patterns from four examples. Some people mostly receive messages rather than send them; for them, "too few openers to template" is the honest result, and the reply section below may still be worth building.

**Cluster**

Split first by format (`invite_note`, `inmail` or `dm`), then by language if the user writes openers in more than one, then by intent.

Let the intents come from the messages. These are common ones, to start from, not a list to force the data into:

- Cold open, no prior context
- Reaction to a signal: funding, job change, a post, a launch, hiring
- Warm intro via a mutual, an event, or shared content
- Follow-up right after a connection was accepted
- Re-engagement after silence

Name each cluster after what the user is actually doing. A recruiter's "candidate approach", an investor's "founder sourcing" or "intro request", a founder's "customer check-in" are better names than a generic label, and the user will recognise them.

Cross-cut by audience from `headline`.

For each cluster of 3 or more, extract:

- **Skeleton**: the move sequence. Opener, why now, relevance, ask, close.
- **Variables**, using the vocabulary below.
- **Length** range in words.
- **Reply rate**: replies over sends, always with absolute counts, never a bare percentage.
- **Ignored count**, for invite note clusters: how many of this variant are still pending 7 or more days after sending.

### Reply and follow-up moves

Look at every `my_messages` entry at position 2 or higher, from conversations where `has_cursor` is false and `is_group` is false (keep the others for voice, exclude them from template clustering).

Use `preceding_message` to split into two kinds before clustering either one:

- **Replies**, where `preceding_message.sent_by_me` is `false`. The trigger is what they said. Group by what that inbound message was doing (asking about pricing, expressing interest, pushing back, asking a logistics question, going quiet then resurfacing) and let the clusters emerge from what the data actually shows. Reply triggers vary too much from one user to the next to predefine.
- **Nudges**, where `preceding_message.sent_by_me` is `true`. This is a follow-up on the user's own message that never got a reply. Cluster these on their own, separate from replies, since the trigger is silence rather than something said.

Nudges get their own bucket at a lower bar than the rest of this step: 3 examples is enough to report, because a silence follow-up pattern is worth surfacing even when thin, and the low-confidence flag already covers under 5. Do not fold nudges into a reply cluster just because the count is small.

For each cluster of 3 or more, extract:

- **Skeleton**: the move sequence.
- **Variables**, using the vocabulary below.
- **Trigger**: for replies, a short generic description of what prompted it (described rather than quoted, since real text gets scrubbed at Save anyway). For nudges, the typical gap: how many days after the unanswered message this was usually sent.
- **Length** range in words.
- **Continuation rate**: of this move, how many led to another reply from them. Absolute counts. This is a different measurement from opener reply rate and must not be merged into the same table or ranked against it.
- For nudges specifically, also report how many eventually got a reply at all versus never did.

Do not restate voice rules in either section. They live in the voice profile. If templates were built without voice, keep a short voice note in the template file so it still stands alone.

### The comparison

This is the headline finding and it goes above the templates. Users care more about which approach works than about any single template.

For openers: compare clusters against each other on reply rate, with counts. For example: signal reaction 18/44 replied, cold open 6/51 replied. Say what the difference suggests and what it does not prove.

For replies and follow-ups: compare separately, on continuation rate, with counts. State plainly that this is a different metric measuring a different thing, not a second ranking of the same list. Call out the nudge finding specifically since it is usually the most actionable one: what share of unanswered threads got revived, and roughly how long after silence a nudge stops paying off if the data shows a cliff.

Where sample sizes are small, say so rather than ranking on noise. Under 5 sends is directional at best.

For invite notes, report reply rate alongside the ignored count. Do not compute a single acceptance percentage. Accepted invites whose conversation fell outside the sample are invisible, which biases any such number downward, and the pending list is capped at 100. Two honest numbers beat one fake-precise one. If the invitations response came back truncated, say so: ignored counts are a floor rather than a total.

### Variable vocabulary

Only use these slots. They are named after the data source that fills them, so the drafting skill knows where to look.

~~~
{first_name} {company} {role}              profile
{mutual_connection} {shared_group}         network
{trigger_event}                            funding, job change, post, launch, hiring
{shared_context}                           event, content, prior meeting
{last_touchpoint} {last_call_topic}        CRM, email, call transcripts
{their_question} {their_objection}         reply triggers, from the inbound message
{my_ask} {cta}                             the user's intent
~~~

If a cluster genuinely needs a slot outside this list, name it after what would fill it. Never emit a vague slot like `{something_relevant}`. The drafting skill cannot fill what it cannot identify.

## Step 8: Review

Ask, one topic at a time.

**Voice**: present the 6 or so strongest rules, each with its count and where it holds. Confirm, correct, or drop. A user who says "actually I never do that" is giving you better data than the sample.

**Opener templates**: at most 6 candidates, best reply rate first. For each: name, reply rate with counts, skeleton, one anonymized example. Keep, merge, or drop.

**Reply and follow-up templates**: at most 4 candidates, best continuation rate first, but always include the strongest nudge cluster regardless of where it ranks, since silence follow-ups are the ones most likely to get buried under higher-continuation reply clusters. For each: name, whether it is a reply or a nudge, continuation rate with counts, skeleton, one anonymized example. Keep, merge, or drop.

Do not dump everything in one wall of text.

## Step 9: Save

**Scrub first.** Every real name, company, and identifying detail becomes a variable slot or a placeholder. Zero names of other people in either file.

**Extract structure, not text.** Verbatim messages get sent verbatim and read like a bot. The value is the skeleton plus the rules.

**Where.** In the working folder root when there is one. Otherwise as downloadable files or documents, with one line telling the user to keep them where their AI tool can read them next time.

### Voice profile

Either a new `linkedin-writing-voice.md`, or a LinkedIn section appended to the existing file, per the Step 1 answer.

~~~markdown
# LinkedIn writing voice
<!-- generated {date} | {N} substantive messages from {C} conversations + {I} invite notes | {date range} -->

## Core voice
Three or four sentences describing how this person writes. Plain description.

## Languages
Which languages, with message counts, and what decides which one is used.
Omit this section for a single-language profile.

## Rules
One table per language when there are several.

| Rule | Holds in | Evidence |
|---|---|---|
| lowercase greeting, no comma | openers, replies | 61 of 74 |
| no sign-off on replies | replies | 88 of 91 |

## Formal or informal address
Only for languages that have the distinction. Which form, with whom, with counts.

## Invite notes
Rules that apply only to the 300 character format. Do not apply these to DMs.

## Register shifts
Differences by audience, only where the sample supports it. Otherwise say there is
no evidence of a shift.

## Never does
Observed anti-patterns with counts. Things absent from the corpus.

## Anti-slop list (generic, edit freely)
Not derived from your messages. These are common AI tells in English. Delete
anything you disagree with, add your own, including for your other languages.

- "I hope this finds you well" and any variant
- "I wanted to reach out"
- "It's not just X, it's Y" and the same shape as a two-sentence fragment
- Tricolons everywhere. Three-item lists as a default rhythm.
- "delve", "leverage", "unlock", "game-changer", "revolutionize"
- Rhetorical question as an opener
- Enthusiasm by exclamation mark
- "As someone who..."
- Closing by restating the opening
- Em dashes. Common tell, but genuinely used by some people. The Rules table
  above says whether you use them. Trust that over this line.

## Low confidence
Under 10 messages supporting. Directional only.
~~~

### Template library

`linkedin_msg_templates.md`. The shape is fixed because it is the interface to the drafting skill:

~~~markdown
# LinkedIn message templates
<!-- generated {date} | {N} conversations, {M} pending invites | {date range} -->

## What works: openers
| Approach | Format | Sends | Replies | Rate | Confidence |

One paragraph on what the comparison suggests.

## Voice
See linkedin-writing-voice.md. (Or, if voice was not extracted, a short
voice note derived from the same messages so this file stands alone.)

## Opener templates

### O1. {name}
- **Format:** invite_note | inmail | dm
- **Language:** {language}
- **Use when:** {the matching condition, written for the drafting skill}
- **Sends / replies:** 12 / 5
- **Skeleton:** ...
- **Variables:** {first_name}, {trigger_event}
- **Example:** ...

## What works: replies and follow-ups
| Approach | Kind | Instances | Continued | Rate | Confidence |

One paragraph on what the comparison suggests, including the nudge finding
(share of unanswered threads revived, and the point where nudging stops paying off
if the data shows one).

## Reply and follow-up templates

### R1. {name}
- **Kind:** reply | nudge
- **Language:** {language}
- **Use when:** {the matching condition: what the inbound message was doing, or
  how long the thread had gone quiet}
- **Instances / continued:** 9 / 4
- **Skeleton:** ...
- **Variables:** {their_objection}, {last_touchpoint}
- **Example:** ...

## Anti-patterns
Things this user never does. Do not reintroduce them.

## Low confidence
Openers under 5 sends, replies and nudges under 5 instances. Directional only.
~~~

Every template needs an explicit **Use when**. That is how the drafting skill selects one instead of guessing.

## Step 10: Check it

Only when a voice profile was written.

Hold back five real messages from the corpus, spread across the languages in the profile. For each, write a one-line brief describing what it was doing, then draft a replacement from the profile alone without looking at the original. Show both side by side.

Ask whether the drafts sound like them. Where they miss, ask what is off and fix the profile. A style file nobody trusts gets ignored.

## Step 11: Wire it up

The files are inert until something tells the assistant to read them. Offer both hooks, once each, and do not push.

**A pointer in their instructions.** One or two lines, wherever this environment keeps standing instructions (`CLAUDE.md`, project instructions, custom instructions):

> When drafting LinkedIn messages, read linkedin_msg_templates.md and linkedin-writing-voice.md first. This covers openers, replies, and follow-ups.

A pointer, not the content, so it costs a line of context rather than the whole library. In a tool with no file access, the equivalent is adding the two files to the project's knowledge.

**Drafting skills.** If you can list the user's installed skills, pick out any that write outreach, messages, sequences, or follow-ups, and ask which should reference these files. If you are able to edit skills, offer to add the line yourself. The Groovin companion skill `draft-linkedin-message` already reads both files by these names: if it is installed, say the two are ready to be used together; if it is not, mention it exists and leave it there.

Then close with two offers, once each:

- If invite notes were thin in the sample, offer to take pasted examples.
- If a voice profile was built, note that LinkedIn is one channel and their sent email would deepen it, particularly for anything longer than a DM. Leave it with them.

---

## Failure handling

- **429 or 5xx on a chat read**: wait briefly, retry once. If it fails again, stop, save state when you can, and tell the user to pick it up later.
- **Every Groovin call failing, including after it was working**: the connection has expired. Tell the user to reconnect Groovin in their connector settings. Do not retry, do not speculate about account restrictions.
- **A result that starts with "Groovin connector problem"**: relay it and follow what it says.
- **Under 15 usable conversations, or under 15 substantive messages**: say it. Offer to widen. Do not present four examples as a pattern.
- **No clear clusters**: say the messages are too varied to template. That is a finding, not a failure to cover up. This applies separately to openers and to replies/follow-ups; one can cluster cleanly while the other does not.
- **Corpus mostly AI-drafted**: say so and stop. A profile built on it would be worse than no profile, because it would be trusted. Offer to work from whatever predates the tool, or from pasted examples they know they wrote.