Research to LinkedIn

Purpose

Convert technical or research work into a LinkedIn post a non-specialist can follow and a specialist can respect, without inflating the work's maturity, scope, or strength of evidence. Research communication usually fails in one of two directions: it is unreadably dense, or it is readably wrong. This skill takes a third path: plain language, exact claims, visible status.

When to use this skill

• The user wants to write about their own research: paper, preprint, working paper, thesis, course project, internal study
• The user wants to summarize someone else's published work
• The user ran an experiment or survey and wants to share early results
• The user says "write about my paper", "share my research", "explain my thesis simply", or similar

Required inputs

1. The research itself: a paper, draft, notes, or a faithful description
2. The user's role: author, co-author, supervisor, or outside summarizer
3. The current status (see the status ladder below). If the user does not state it, the skill asks before drafting.
4. What the user is allowed to share. Unpublished results, employer studies, and co-authored work all have permission constraints.

Optional inputs

• Target audience (general LinkedIn, domain peers, potential collaborators, recruiters)
• The single takeaway the user most wants to land
• Links (paper, preprint, code, data)
• Plain-language translations the user already likes

Workflow

1. Establish the rung. Place the work on the status ladder (research-claims.md): idea, protocol, experiment, preliminary result, working paper, preprint, or peer-reviewed publication. State the rung in the post, in plain words.
2. Triage claims. List every claim the post might make. Mark each KNOWN (from the paper or the user), INFERRED, or UNKNOWN. In research posts, UNKNOWN claims are rejected outright, not softened.
3. Extract the honest core. Find the one result or question that matters, with its exact scope: sample, duration, conditions, selection method.
4. Translate. Write a one-sentence plain-language version of the core claim. Check it against the source: if a specialist would say "that is not what it says", rewrite.
5. Attach the caveats. Sample size, self-selection, missing statistics, single model or dataset, whatever limits the work. These go in the post body, not in a footnote.
6. Draft at 100 to 250 words: hook, plain-English core, method with scope, caveats, status, link, invitation.
7. Run the claims audit (output format below). Every sentence in the post must trace to the source or the user.
8. Deliver the post and the claims audit.

Truth and credibility rules

This skill enforces research-claims.md in full. The non-negotiables:

• The status ladder is law. NEVER call a working paper "published research". NEVER call a preprint or draft "published". If it has not passed peer review, the post says so in those words.
• Never invent: participants, sample sizes, statistical significance, citations, experiments, measurements, results, venue acceptances, co-authors, lab affiliations.
• The verb "proves" is banned. Research "suggests", "supports", "observed", "found in [scope]".
• Numbers travel with their scope in the same sentence: "7 of 12 functions I selected", never "58% more bugs" naked.
• If only the abstract of someone else's paper was read, the post may only claim what the abstract claims.
• The user's opinion on the work is welcome and must be labeled as opinion.

Writing rules

• Default voice per voice-guide.md; 100 to 250 words.
• Lead with the question or the finding, never with "I'm pleased to announce that our paper...". The paper's existence is metadata, not the hook.
• Every technical term gets one plain-language gloss on first use.
• Analogies: at most one, structurally accurate.
• The caveats paragraph is mandatory and stays in even when the user finds it uncomfortable. The skill drafts it kindly and firmly.
• Banned: "breakthrough", "game-changing research", "groundbreaking study", "scientists are amazed".

Output format

[The post, ready to copy]

[Claims audit]
CLAIM 1: "<sentence from the post>" -> KNOWN, from <paper section/user statement>
CLAIM 2: "<sentence>" -> INFERRED, qualified as "<qualifier>"
...
STATUS STATED: <rung, in the words the post used>
INVENTED: none | <list any claims that could not be traced; these are removed before delivery>

The audit's job is to show the user exactly which sentence carries which evidence. If any claim traces to nothing, remove it and redeliver.

Worked example

Input (summary): a master's student's working paper; question: does full file context help a code-review LLM flag more real defects; 12 open-source Python functions with known defects, selected by the student; 7 of 12 flagged with context, 5 of 12 without; no statistics; not peer reviewed; hosted on a university page.

Output (the post):

A small research question I've been testing: does giving a code-review
LLM the full file, instead of just the changed lines, help it flag more
real defects?

Setup: 12 open-source Python functions with known defects. Two runs: one
with full file context, one without.

Result so far: 7 of 12 flagged with context, 5 of 12 without.

Caveats: 12 functions I selected myself, so the sample is small and
biased toward what I thought to test. No statistics here; the gap could
shrink or reverse on different data.

This is a working paper, not a peer-reviewed publication.

I'm sharing it to find people who have run similar comparisons. What did
your setup look like?

Working paper: <link>

Full walkthrough with the claims audit: examples/research-working-paper.md.

Edge cases

• The user wants the result to sound bigger. Do not inflate the rung, the sample, or the strength. Offer instead to make the honest version more vivid: concrete details, better structure, clearer translation.
• Multi-author paper. Confirm the user's contribution is described accurately ("first author", "co-author on the evaluation") and that co-authors are comfortable with the post.
• Confidential or embargoed research. Draft nothing until the user confirms what is shareable; if nothing is, suggest writing about the research question rather than the results.
• Negative or null results. These are welcome and valuable; apply the same audit. "We found no effect in [scope]" is a fine post.
• The user is summarizing a famous paper. Follow the summarizing-others rules: fidelity, hedges preserved, source linked, opinion labeled.
• Preprint with revisions in progress. Use the preprint rung and note that a revision is under review only if the user states it and a venue exists.

When NOT to use this skill

• The work is an engineering project with no research claims: use project-post-writer or github-to-linkedin.
• The user wants ongoing lab progress updates: use build-in-public with the failure rules applied to experimental setbacks.
• The user wants a full public explanation of a paper for a blog or conference: different artifact, different length; the skill can point at the structure but should not pretend LinkedIn is the right venue.

Shared references

• ../../references/research-claims.md — the status ladder and hard prohibitions; this skill's parent rule set
• ../../references/credibility-rules.md — the fact triage system
• ../../references/voice-guide.md — voice rules and banned patterns

These paths assume the full repository is present. This skill works standalone: the rules above are the core, the references add depth.