Update to LinkedIn Animated Infographics

{
  "description": "Use when writing or rewriting LinkedIn captions for repos, plugins, AI workflows, GIFs, infographics, technical ideas, curated collections, tool explainers, belief-correction posts, or first-comment link payloads that need a strong mobile hook and mechanism-first narrative",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 375
    },
    {
      "relative_path": "references/quality-gates.md",
      "size_in_bytes": 3012
    },
    {
      "relative_path": "references/reference-examples.md",
      "size_in_bytes": 3308
    }
  ],
  "name": "linkedin-caption-narrative",
  "skill_md_contents": "---\nname: linkedin-caption-narrative\ndescription: Use when writing or rewriting LinkedIn captions for repos, plugins, AI workflows, GIFs, infographics, technical ideas, curated collections, tool explainers, belief-correction posts, or first-comment link payloads that need a strong mobile hook and mechanism-first narrative\n---\n\n# LinkedIn Caption Narrative\n\n## Purpose\n\nWrite high-signal LinkedIn captions that read like a useful explanation someone would stop to read, not launch copy pretending to be conversational\n\nCore principle\n\n**Hook with a real tension, name the thing early, explain the mechanism with concrete nouns, let the visual carry part of the story, and move link-heavy utility into the first comment when that improves the read**\n\nThis Skill is designed for technical and AI-adjacent posts where the artifact itself matters: repositories, Plugins, Skills, workflows, models, research methods, animated infographics, GIFs, catalogues, and practical belief corrections\n\n## Use when\n\nUse this Skill when the user asks for any of the following\n\n- a hooky or stop-scroll LinkedIn caption\n- a caption for a GitHub repo, Plugin, Skill, workflow, AI tool, model, or technical resource\n- a caption that accompanies a GIF or animated infographic\n- a curated list or catalogue of repos, tools, or workflows\n- a belief-correction educational post\n- a recent-signal or research-process post\n- a caption plus first comment\n- a rewrite inspired by high-signal AI, developer, marketing, GTM, or technical LinkedIn posts\n\nDo not use this as a generic thought-leadership template when there is no real mechanism, artifact, evidence, or practical idea to explain\n\n## Inputs\n\nResolve these from the user material before drafting\n\n1. **Thing**: what exactly is being shown or discussed\n2. **Reader**: who would care and why\n3. **Tension**: what friction, misconception, repeated task, or missing context creates interest\n4. **Mechanism**: what actually happens\n5. **Specifics**: names, commands, steps, inputs, outputs, limits, categories, or verified numbers\n6. **Proof**: only evidence supplied or verified\n7. **Visual job**: what the GIF or infographic already communicates\n8. **CTA**: one useful next action\n9. **First-comment payload**: links, setup steps, sources, install commands, or long catalogue entries\n10. **House style**: punctuation, banned language, dialect, capitalization, formatting, or other explicit user rules\n\nIf a factual claim, number, benchmark, price, star count, license, compatibility statement, performance claim, testimonial, or product behavior is not supported, do not invent it\n\n## Outputs\n\nReturn the finished caption first\n\nReturn a finished first comment when the user requests one or when links, commands, sources, or a long catalogue would make the caption harder to read\n\nDo not expose pattern names, scoring, internal routing, or drafting notes unless the user asks for them\n\n## Core narrative grammar\n\nThe dominant transferable pattern is\n\n**Tension → Named Thing → Mechanism → Specifics → Why It Matters → Visual Bridge → Action**\n\nNot every post needs every stage\n\nThe important rule is that each block must advance the idea instead of restating the hook\n\n### 1. Tension\n\nOpen on something recognizable and concrete\n\nStrong tension types\n\n- a tool behaves badly in a specific way\n- a repeated task has become annoying\n- a common assumption is incomplete\n- a category changes faster than the research process\n- a metric looks good but hides the real problem\n- too many resources create a coordination problem\n- a technical constraint blocks a practical outcome\n\nGood shapes\n\n- `Most OCR tools choke on messy documents`\n- `Most AI tools talk too much`\n- `Your page can rank first and still never become the answer`\n- `I built so many AI Skills that using them became its own workflow`\n\nWeak shapes\n\n- `AI is changing everything`\n- `This tool is amazing`\n- `The future of work is here`\n- `I found a game-changing repo`\n\nReject a hook if another product name can be swapped in without changing the meaning\n\n### 2. Named Thing\n\nName the artifact early\n\nUseful forms\n\n- `Meet {repo-name}`\n- `The {repo-name} GitHub repo`\n- `This Skill`\n- `This Plugin`\n- `The stack`\n- `The visual below`\n\nNamed things reduce vagueness and make the post inspectable\n\n### 3. Mechanism\n\nExplain what happens using plain verbs\n\nPrefer\n\n`A hook grabs Claude's reply after it finishes`\n\nOver\n\n`It improves communication with AI`\n\nPrefer\n\n`Searches recent activity across Reddit, X, YouTube, Hacker News, GitHub and prediction markets`\n\nOver\n\n`It gives you better research`\n\nMechanism is the credibility layer\n\n### 4. Specifics\n\nUse details that can be checked or acted on\n\n- exact commands\n- repo names\n- model names\n- supported inputs\n- output format\n- licenses\n- hardware\n- pricing\n- benchmark scores\n- star counts\n- steps\n- concrete use cases\n\nSpecificity must serve the decision, not decorate the copy\n\n### 5. Why it matters\n\nTranslate the mechanism into one or two practical consequences\n\nExamples\n\n- `If Ollama is down, Claude still works normally`\n- `The useful answer can be extracted without decoding four paragraphs first`\n- `You stop reopening the same context every session`\n\n### 6. Visual bridge\n\nWhen a GIF or infographic is attached, use one short bridge at most\n\nExamples\n\n- `The GIF below is how I think about the handoff`\n- `The visual shows where each specialist enters`\n- `The animation makes the sequence easier to see`\n- `The page inside the GIF is an example, not a client result`\n\nDo not narrate every frame\n\n### 7. Action\n\nChoose one practical next action\n\n- open the repo\n- install the Skill\n- try one Plugin\n- save the setup\n- inspect the first comment\n- answer one practical question\n\nAvoid vague asks such as `Thoughts?`\n\n## Caption archetypes\n\nChoose one primary archetype and stay in it\n\n### A. Repo Explainer\n\nUse when one repo, tool, Skill, model, or Plugin is the subject\n\nShape\n\n```text\n{specific friction}\n\n{one-line solution}\n\nMeet {name}\n\n{verified free/open-source/local/license line when relevant}\n\nHere's what it does:\n\n{mechanism}\n↳ {practical consequence}\n\n{mechanism}\n↳ {practical consequence}\n\nWhy it matters:\n\n{one concrete consequence}\n\n{link location}\n\nP.S. {easy practical question}\n```\n\n### B. Stack Catalogue\n\nUse when the value comes from a collection\n\nShape\n\n```text\n{how the collection became necessary}\n\n{count + collection + what unifies it}\n\n{CATEGORY}, {what the category controls}\n\n✦ {item}\n✦ {item}\n✦ {item}\n\n{one-line category payoff}\n\n{next category}\n\n{compounding line}\n\n{link location}\n\nP.S. {which one would you use first}\n```\n\nCritical rule\n\nThe collection needs an organizing model\n\nA raw list is not a catalogue story\n\n### C. Operating Story\n\nUse when the interesting part is how work moves\n\nShape\n\n```text\n{repeated workflow problem}\n\n{what changed in the way the work is handled}\n\n{specialist 1}\n↳ {job}\n\n{specialist 2}\n↳ {job}\n\n{specialist 3}\n↳ {job}\n\nThe interesting part is the handoff\n\n{how the work moves between them}\n\n{visual bridge}\n\n{first comment}\n\n{question}\n```\n\nGood for Plugin stacks, agent workflows, multi-step research, and production pipelines\n\n### D. Belief Correction\n\nUse when a familiar metric or assumption is incomplete\n\nShape\n\n```text\n{strong belief correction}\n\n{why the normal interpretation is incomplete}\n\nThat usually comes down to {N} things\n\n1. {factor}\n↳ {specific behavior}\n\n2. {factor}\n↳ {specific behavior}\n\n3. {factor}\n↳ {specific behavior}\n\n{diagnostic question}\n\n{visual disclaimer when needed}\n\n{reader question}\n```\n\n### E. Recent-Signal Story\n\nUse when freshness is the problem\n\nShape\n\n```text\n{what goes stale}\n\n{how quickly the category changes}\n\n{named sources and what each contributes}\n\nThe interesting part is {comparison or synthesis}\n\n↳ collect\n↳ compare\n↳ filter\n↳ synthesize\n\n{practical use cases}\n\n{visual bridge}\n\n{question about manual source checking}\n```\n\n### F. Visual Companion\n\nUse when the visual already carries much of the narrative\n\nShape\n\n```text\n{one-line tension}\n\n{one-line frame for the visual}\n\n{2 to 5 points the viewer should notice}\n\n{what the animation makes easier to understand}\n\n{link or source location}\n\n{one question}\n```\n\nKeep this shorter than the visual's information density would suggest\n\n## Hook procedure\n\nBefore drafting the body, generate 8 to 12 hook candidates silently\n\nUse at least three different hook mechanisms\n\n- friction\n- belief correction\n- concrete curiosity\n- catalogue scale\n- direct utility\n- operating problem\n\nReject hooks that\n\n- could introduce almost any AI product\n- depend on hype adjectives\n- need the next line to explain what the first line meant\n- create suspense around a trivial fact\n- promise an unsupported result\n- sound written to impress rather than clarify\n\nKeep line 1 compact enough to survive mobile truncation when the language allows it\n\nRoughly 55 characters is a useful default, not a hard law\n\n## Scan rhythm\n\n- keep most paragraphs to one or two short lines\n- allow uneven paragraph lengths\n- put one main idea in each block\n- use whitespace deliberately\n- do not turn every sentence into a standalone paragraph when it damages flow\n- use section labels only when they make a dense technical post easier to scan\n- use `↳` for mechanism, clarification, consequence, or sub-step\n- do not use `↳` as decoration\n- keep emoji sparse and structural when the writer uses them\n\n## First comment\n\nThe first comment has a separate job\n\nIt carries utility without slowing the main caption\n\nUse it for\n\n- repo or Plugin links\n- installation commands\n- setup steps\n- source references\n- long resource catalogues\n- exact paths or technical instructions\n\n### Link index pattern\n\n```text\nAll links from the visual 👇\n\n1. {Name}\n{one-line job}\n{URL}\n\n2. {Name}\n{one-line job}\n{URL}\n\nStart with the one closest to a task you already repeat\n```\n\n### Install guide pattern\n\n```text\nSetup:\n\nStep 1\n↳ {command}\n\nStep 2\n↳ {command}\n\nStep 3\n↳ {command}\n\nRepo:\n{URL}\n```\n\n### Source note pattern\n\n```text\nSources / references:\n\n↳ {source}\n↳ {source}\n↳ {source}\n\nThe visual simplifies the idea, so use the sources above for the full context\n```\n\nFirst-comment rules\n\n- do not repeat the whole caption\n- do not add a second sales pitch\n- do not hide a material limitation in the comment\n- preserve exact URLs\n- keep names in the same order as the visual when order matters\n- if two links use the same display name, distinguish the variants when known\n\n## Visual companion contract\n\nCaption and visual should divide the communication job\n\nCaption owns\n\n- reason to care\n- tension\n- interpretation\n- mechanism that is not obvious visually\n- practical consequence\n- CTA\n\nVisual owns\n\n- sequence\n- topology\n- handoff\n- comparison\n- hierarchy\n- before and after\n- category grouping\n- spatial relationships\n\nAsk two questions before finalizing\n\n1. If the GIF disappears, what useful information is missing from the caption\n2. If the caption disappears, what useful information is missing from the GIF\n\nBoth answers should contain something important\n\nIf the caption merely narrates the animation, compress it\n\nA visual can illustrate a process without proving it\n\nUse `shows`, `maps`, `illustrates`, or `explains`\n\nDo not imply case-study evidence unless the supplied evidence supports it\n\n## Voice and anti-slop rules\n\n- plain English over polished corporate prose\n- specific nouns over adjectives\n- mechanism before praise\n- useful roughness over suspiciously perfect symmetry\n- preserve normal technical vocabulary\n- no fake urgency\n- no invented anecdotes\n- no invented proof\n- no generic motivational conclusion\n- no repeated recap\n- no empty superlatives\n- no em dash\n- avoid repeated `not X, but Y` constructions\n- avoid generic transition phrases\n- avoid engagement bait disguised as a question\n\nHouse style outranks this Skill\n\nIf the user bans terminal periods, remove terminal periods from visible copy while preserving dots required inside URLs, version numbers, decimals, commands, filenames, domains, and other technical literals\n\nIf the user supplies a voice sample, derive cadence and vocabulary from that sample instead of copying example phrasing from this Skill\n\n## Procedure\n\n1. Resolve the inputs and evidence boundary\n2. Read `references/reference-examples.md` when the user asks to match the supplied style family or when pattern choice is uncertain\n3. Pick one archetype\n4. Generate and filter hook candidates\n5. Draft the narrative around one primary idea\n6. Name the real artifact early\n7. Explain mechanism before praise\n8. Add only supported specifics\n9. Divide the communication job between caption and visual\n10. Move link-heavy utility into the first comment when useful\n11. Apply the user's house style as hard constraints\n12. Read `references/quality-gates.md`\n13. Revise until every hard gate passes\n14. Return only the requested caption and first comment unless critique is requested\n\n## HOLD conditions\n\nReturn a HOLD only when the requested output depends on a claim that cannot be supported without inventing or materially changing the user's approved premise\n\nExamples\n\n- unsupported benchmark or result must remain in the hook\n- exact product behavior is unknown and cannot be safely generalized\n- a visual is described as a client result but the evidence says it is only an example\n- a link or product identity cannot be resolved and exactness is required\n\nOtherwise remove unsupported precision and continue\n\n## Related components\n\nInside the source repository, this Skill complements the canonical `caption` Skill and its broader caption archetype reference\n\nWhen the host provides the repository tools, run the existing copy-slop checker where appropriate\n\n```bash\npython3 tools/copy_slop_check.py --file <caption.txt>\n```\n\nThis checker is supplemental\n\nThe final narrative judgment, evidence boundary, first-comment split, and visual-caption division remain the responsibility of this Skill\n\n## Research gates\n\nApply these conceptual gates to every visible draft\n\n- **prose-specificity**: prefer checkable names and mechanisms over generic language\n- **voice-preservation**: preserve the writer's natural vocabulary and useful cadence\n- **evidence-traceability**: every factual precision must come from supplied or verified evidence\n- **visual-alignment**: caption and visual must not contradict each other\n- **house-style-compliance**: explicit user rules are hard constraints\n"
}