メニュー
Use when composing LinkedIn posts - writes post text and carousel/image assets to a local directory for manual review and publishing. Optimized for the 2026 LinkedIn algorithm (dwell time, Golden Hour, document carousel format).
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | linkedin-api |
| description | Use when composing LinkedIn posts - writes post text and carousel/image assets to a local directory for manual review and publishing. Optimized for the 2026 LinkedIn algorithm (dwell time, Golden Hour, document carousel format). |
This skill does not publish to LinkedIn. It produces a self-contained bundle (post text + images / carousel pages) in a local linkedin/ directory. The user uploads and publishes manually at https://www.linkedin.com/feed/?shareActive=true.
Why save-only in 2026: LinkedIn's March 2026 Authenticity Update demotes automation-pattern content. The REST API also silently truncates text past ~3000 chars and adds round trips that risk shadow-truncated posts. Manual upload gives full control over preview, media order, and timing.
Every post is a folder bundle:
<project>/linkedin/
post.txt # first-3-line hook + body + hashtags, final copy-paste-ready
01-cover.png # assets in upload order (1-9 images or 5-10 PDF pages)
02-*.png
...
carousel.pdf # optional, for Document-post upload (best-performing format)
publishing-checklist.md # optional short checklist for the user
Default target directory: <project-root>/docs/linkedin/ or <project-root>/linkedin/. Ask the user if the path is ambiguous.
LinkedIn's 2026 algorithm ranks by dwell time above everything else - the actual seconds a reader spends on the post. Likes barely register. Comments are weighted ~15x a like. Every authoring choice should maximize read-time and comment substance.
| Read duration | Engagement rate | Distribution |
|---|---|---|
| 0-3 s | 1.2% | Limited |
| 11-30 s | 6.1% | Extended |
| 31-60 s | 10.2% | Maximum |
| 61+ s | 15.6% | Exceptional (~2.5x wider reach) |
The first 60-90 minutes after posting determine distribution tier. Only ~5% of posts that underperform in hour one ever recover. Tactics:
Comments are 15x a like in the ranking model, but LinkedIn weighs comment quality:
| Format | Avg engagement | Notes |
|---|---|---|
| LinkedIn Live video | 29.6% | Premium, rare, highest reach |
| PDF / Document carousel | 6.6% | 278% above video, 596% above text. Default recommendation for technical / B2B |
| Multi-image carousel | ~6.6% | Similar weight to PDF but less searchable |
| Native video (< 90 s, vertical) | 5.6% | Growing 2x faster than other formats. Hardcoded captions required |
| Text post | 2-4% | Baseline |
| Single image | Below text | Lowest of the standard formats |
Default for technical content: PDF document carousel, 5-10 slides at 1080×1080. Every swipe is tracked as a dwell-time increment, multi-slide interaction is measured, and numbered frameworks ("5 lessons...", "3 mistakes...") add a further 20-30% to dwell.
| Asset | Dimensions | Aspect | Max size |
|---|---|---|---|
| Single image | 1200×627 | 1.91:1 | 5 MB |
| Multi-image carousel | 1080×1080 each | 1:1 | 10 MB each |
| PDF document carousel | 1080×1080 per page | 1:1 | 100 MB, up to 300 pages |
| Slide deck (16:9 alternative) | 1920×1080 | 16:9 | 100 MB |
| Banner | 1128×191 | 6:1 | 4 MB |
| Video (landscape) | 1920×1080 | 16:9 | 5 GB, 3 s to 10 min |
| Video (vertical) | 1080×1920 | 9:16 | 5 GB, 3 s to 10 min |
FIG_LANG=en-style switch that writes to an images_en/ dir (leaving the original-language figures untouched), then embed the English PNG with <image href>. Keep schematic SVG for the architecture / pipeline / results slides; use real data on the proof slides.resource_report.json / timing_report.json / sim log), cited by path - not a finding/history/retrospective doc, a prior post, a sibling slide, or memory. If you cannot cite the report, RE-RUN the measurement workflow to get the exact value before posting. When you correct or add one number, re-trace ALL its siblings (the whole sweep / table) from the same source - one non-reproducing number means the set is suspect, and consistency across slides is NOT proof a number is real (it can be consistently wrong everywhere). Full rule + the Viterbi failure case: the svg-diagram skill.Default to clean technical-diagram style, not marketing-social style. Carousel slides for technical audiences (engineers, researchers, hardware / ML / infra professionals) read as credible when they look like figures from a research paper or trade magazine, not like influencer promo graphics.
Prefer this style (proven to work for technical B2B):
#eff6ff → #dbeafe for blue cards, #f0fdf4 → #dcfce7 for green, #fefce8 → #fef9c3 for yellow). White canvas background.rx="14" to rx="16") with thin 2-2.5 px colored strokes that echo the card's accent hue.#334155, blue #1971c2, green #059669, amber #ca8a04, red #dc2626. Dark text colors matching stroke (#1971c2 heading on blue card, #065f46 on green, #854d0e on amber).#1e293b) with white text for slot markers like LESSON 1, PROOF, TAKEAWAY.#64748b below the bold title.#94a3b8 at bottom-right: 3 / 7.font * 370 / 1080. The 17-22px body floor above renders only ~6-7.5px on a
phone — fine for a glanceable slide, too small for a dense one. The fix for a dense slide is the
same as for any figure: put FEWER items per slide (split across slides) rather than shrinking
text, and lean on the svg-diagram skill for the compaction layouts (stacked cards, fewer-
boxes+ellipsis), the inline-Feather-icon enrichment, the figure-text-accuracy sweep (every
number AND framing word on a slide must match the post text), and the box-fit audit (run
svg_audit.py on every authored slide so no label centered in a box overflows it - see the
workflow step 3 below).Avoid this style (looks AI-marketing, lowers perceived credibility for technical readers):
#a855f7 → #3b82f6) as dominant color<linearGradient>)Minimum in-slide font is still 24 pt — but a dense technical slide with 17-22 pt body text inside 60+ px card sections reads well because the card itself acts as visual structure. A slide with one giant 80 pt headline and nothing else reads as "AI slop" even though it passes the minimum-font check.
Reference / reuse rule: if the same article has a Chinese WeChat version with clean technical diagrams, re-author those actual diagrams at 1080×1080 in English (the full system/micro-architecture, the real datapath, the specific schematic) — do NOT downgrade them to plain text-block slides with one big number. The rich figure is the credibility signal. Plain blocks read as "AI slop". Always pull the source article's diagrams first and mirror their content.
Lead a technical carousel with one real architecture / overview figure (slide 2, right after the cover): a labeled block diagram of the actual system datapath. It is the strongest credibility signal, it says "this is a real, complete design" rather than a marketing claim. Real result: a decoder carousel gained an architecture figure (LLR memory -> barrel shifter -> check-node unit -> variable-node memory, plus control and the feedback loop) and it anchored the whole deck.
If the source has a real mechanism, DRAW the mechanism, never summarize it as numbered bullets in a colored box. A data hazard becomes a producer -> register -> memory -> consumer figure with a stale-read path and a forwarding bypass; a diagnosis becomes the actual critical-path chain plus the two competing fixes. Real failure: a carousel's "dependency" and "wrong turn" slides were two columns of numbered text and were repeatedly called "not readable / not illustrative"; rebuilding each as a real labeled figure fixed it. Bulleted text is the text-block anti-pattern even inside a nicely-colored card.
When a finished carousel is rejected as "not readable / not attractive" and the fix is a subjective redesign, lock the visual direction before rebuilding. Offer 2-3 concrete style-direction options with tiny preview mockups (editorial-story vs rich-technical-figure vs bold-infographic) and let the user pick, instead of guessing a fourth time. The AskUserQuestion preview field is built for this. Real result: after several misses, one preview question ("rich technical figure" + "lead with technical credibility") nailed the direction and the rebuild landed in one pass.
Reusing one visual template post after post makes the feed look templated and lowers credibility — a real failure: a new carousel was rejected because it looked identical to the author's previous posts (same light-blue frame + slate pill ribbon + royal-blue accent + big-number card). Rotate the style. Each post picks a preset that differs from the immediately previous post (ideally random among the rest), and that fits the story's tone.
Record the choice in the bundle as a one-line STYLE.txt (e.g., dark-scope). Before authoring, read the most recent bundle's STYLE.txt (or eyeball the prior slides) and pick a different preset.
Credible preset palette (every preset still obeys: min 24 pt, dense figures with 3+ blocks, no AI-marketing gradients / glow / hexagon-circuit decorations):
#0b1220), monospace signal/cycle labels, muted neon green/red/cyan, a FAINT line grid (not dotted), terminal/diff panels; reads like a logic analyzer. Best for timing / debug / cycle-accurate stories. Keep neon muted (no glow halos).#edf1f7) + WHITE cards with real (manual) elevation shadows; each card an accent title strip + tinted internal regions; a restrained system (grey ramp + one accent per role: amber = RF/compute, teal = memory/expansion + green/red/blue semantics); a DARK-navy full-bleed cover billboard + a dark summary panel on the results slide. Best for hardware / board / architecture stories. Draw chips as accurate block symbols (NOT boxed rectangles with pins — see svg-diagram "IC / chip / FPGA package accuracy"); use the manual blurred-rect shadow (NOT feDropShadow, which drops the fill in librsvg).Match preset to tone: a debugging / timing story suits dark-scope or blueprint; a strategy piece suits editorial; a hardware / board build suits flat-hardware. Whatever the preset, re-author the article's real diagrams in it.
Default to LIGHT presets when in doubt. Dark-scope can look great in your own preview but darkens further at LinkedIn's thumbnail compression, and dark backgrounds are unforgiving of low-contrast secondary text (muted slate-on-navy turns illegible). Failure case (2026-05-30 ai-rtl-bug-debug): a dark-scope deck was initially produced for a debug story but had readability issues on mobile thumbnail — user explicitly requested a switch to light. The fix went to light-pastel-cards and reads cleanly at every zoom level. Rule: if the story tone suits dark-scope, build it AND verify at thumbnail size before committing. If any text relies on subtle slate-on-dark for hierarchy, switch to a light preset; dark-scope only wins when the deck is dominated by monospace signal/cycle labels with no narrative prose.
These turn a plain deck into a designed one; they came out of a hardware-deck rebuild that took many misses before landing. Web-grounded (Material elevation, Refactoring UI, LinkedIn carousel guides):
#0f172a) while interiors are light; ONE
hook (a huge number/BAN, or a 3-word claim, one accent word) at 72-120pt; an eyebrow/kicker
top-left (13-16px uppercase, tracked, accent) + a SWIPE › affordance; <12 words; at most one
minimal hero motif, never the full block diagram. A cover that is the same figure smaller +=
a title fails.svg-diagram on EXIF-normalizing + verifying annotation positions
against the actual render). It is the strongest "this is real" credibility anchor.When the same story goes to two pages (e.g. a personal page + a company page), produce ONE
carousel.pdf and TWO caption files in the same bundle dir — post.txt and
post-<audience>.txt — not a second slide directory. The slides are audience-neutral
(architecture-forward); only the caption voice differs (first-person build story vs company
capability framing). Note the split in publishing-checklist.md (same PDF, two captions, spaced
18-24 h apart).
LinkedIn's "technical audience" is not monolithic. An FPGA engineer reading an LDPC post does not necessarily know what K_avg means; a hardware verification engineer reading an HFT post does not necessarily know mid-price or TWAP. Even when the audience is technical, the cross-pollination between sub-specialties is high, and an unexplained domain term is the most common reason a reader bounces from the carousel before slide 3.
Two-tier label pattern for domain terms in diagrams: put the technical definition as the primary label, the plain-language gloss as a smaller subtitle below.
K_avg = iters per codeword <-- 24 pt bold, the precise definition
(one LDPC frame) <-- 18 pt italic, the friendly gloss
In the post text, define every domain term on first appearance with a parenthetical gloss, then use the term freely afterward:
Bad: "The 4× K_avg gap stayed."
Good: "The 4× K_avg gap (K_avg = average iterations to decode one codeword,
i.e. one LDPC frame) stayed."
Apply to: every algorithm metric (K, BER, EVM, NMSE), every hardware-block acronym (FE, BE, CNU, BRAM, LUTRAM, SRL), and every project-specific signal name that drives the narrative (first_iter, sum_old, branch_mem). Audience expansion is free; assumed knowledge has a cost.
LinkedIn truncates on mobile at about 49 characters and on desktop at 2-3 lines. The reader has to click "see more" to trigger dwell-time accumulation. Without that click the post dies.
Proven hook patterns:
| Pattern | Template | Example |
|---|---|---|
| Contrarian | "X is not the problem. Y is." | "Hand-writing Verilog isn't the bottleneck. Architecture iteration is." |
| Unexpected stat | " ." | "28 DSP blocks instead of 52. A 46% saving nobody on our team predicted." |
| High-stakes problem | "If you , you're about to hit ." | "If your pipeline breaks every time you change N, you are burning weeks per project." |
| Origin / vulnerable | "Six months ago I . Here's what changed." | "Six months ago I was hand-writing 2000 lines of Verilog per project. Today AI writes them. Here is the tradeoff." |
| Question | "Why does ?" | "Why does AI write better pipelined hardware than most junior engineers?" |
The flat structure above is fine for a pure reference post, but a narrative arc reads as more interesting and earns more dwell time whenever the post is about something you did (an experiment, a debug session, a build, a mistake). Prefer it by default for those.
Arc that works (proven this session - a bulleted feature-dump rewritten as narrative was markedly more readable):
Story-telling craft rules:
Comments are worth 15x a like. Always close with an open question that invites a 5+ word reply.
| Good CTA | Why |
|---|---|
| "What's the part of you'd most want to automate?" | Personal, open |
| "Curious how others handle ." | Invites shared experience |
| "Disagree? I want to hear the counter-case." | Invites contrarian replies (strongest signal) |
| "Which of these surprised you?" | Forces a choice, easy to reply to |
| "What would you add to this list?" | Invites extension, low-effort for reader |
Never use (NLP-flagged, demotes the post):
<Hook: contrarian or specific-number, 1 line>
<Context: 1-2 lines on why this matters now>
<Value payoff, 2-4 lines, with specific numbers>
<Takeaway: 1 line, what the reader should do differently>
<CTA question>
#Tag1 #Tag2 #Tag3 #Tag4
Target length: 900-1300 chars. Pair with 5-10 slides.
Slide 1 (cover): 3-line headline + promise + "swipe →"
Slide 2: Problem framing / agitation
Slide 3-N-2: Solution, one insight per slide, numbered
Slide N-1: Result / proof - charts, stats, screenshots
Slide N: Punchline recap + open-question CTA (same as post body)
<Hook: question or contrarian claim, 1-2 lines>
<Context: 2-3 lines>
<Observation or specific example>
<CTA question>
#Tag1 #Tag2 #Tag3
Target length: 500-900 chars.
Include these in the publishing checklist you give the user:
When this skill is invoked to produce a post:
<project>/docs/linkedin/. Create if missing.rsvg-convert -w 1080 -h 1080 page.svg -o page.pngpython3 ~/.claude/skills/svg-diagram/scripts/svg_audit.py *.svg as a candidate-finder.text-overflows-box flag against the rendered PNG - the width heuristic
(Latin ~0.6em) OVER-reports lowercase-heavy labels ("on the critical path", "phase counter")
and anchor-start text, so many flags are FALSE POSITIVES. Do NOT rewrite a label that the
render shows fitting; over-correcting a false positive is its own failure (see svg-diagram).text-anchor="middle") spills out BOTH ends when its width exceeds the box. Crop the
suspect region if unsure.
Fix a REAL overflow by shortening the text or splitting it across two stacked <text> lines (or
widening the box), never by clipping it or shrinking below the 24 pt floor. This catch is what
was missing: the native slides (cover, problem, fix, dead-end) are where overflows hide; the
embedded article figures were already audited. Real failure: a Viterbi carousel shipped
"branch metric (off the path)" overflowing its 264px box because the slide SVGs were never run
through svg_audit OR eyeballed; the user had to catch it. Box-fit + ribbon-width + line-
splitting rules + the false-positive traps all live in the svg-diagram skill.# Preferred: ephemeral img2pdf via uv (no install, works with no venv active).
uv run --with img2pdf python3 -c "import img2pdf, glob; open('carousel.pdf','wb').write(img2pdf.convert(sorted(glob.glob('0*.png'))))"
# If already on PATH: img2pdf 01-*.png 02-*.png ... -o carousel.pdf
# Do NOT rely on bare `img2pdf`, `convert`, or `uv pip install img2pdf` -- in a
# clean environment all three commonly fail (not installed / no active venv).
post.txt:
svg_audit.py *.svg run, every text-overflows-box flag resolved - real overflows
fixed, lowercase/anchor-start false positives confirmed fitting against the render, and a visual
scan of each rendered slide shows no label crossing a box edge (see step 3). Re-run after edits.wc -c post.txt under 3000, aim for 1000-1300publishing-checklist.md with the manual steps:
V1-V5, Phase N, Tier N, pymodel / golden / leaf / recipe, commit hashes) — meaningless to an outside reader; translate to outcomesScripts at ${CLAUDE_PLUGIN_ROOT}/scripts/ are retained for users who explicitly want programmatic publishing:
oauth-server.py - OAuth 2.0 flowlinkedin-api.py - publish, upload, verifyThe default workflow no longer uses these. If a user explicitly requests auto-publish, warn them:
commentary past ~3000 chars (no error returned)If they still want it, see scripts/linkedin-api.py --help and the published-post truncation fix flow described in commands/post.md (advanced section).