agentleFS
Sign inStart free
yohei1126yohei1126/agent-skills/linkedin-article/SKILL.md

linkedin-article

Skill2 starsChanged 22 days agoMITView on GitHub

Draft or revise English LinkedIn technical articles (Pulse) and feed posts. Do not include repo names, model names, or bot-specific ops.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

22 rules. About 0 are common, 17 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈17

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Write or polish a LinkedIn long-form article

    line 11
  2. Distinctive:

    Write a feed post that announces the same topic

    line 12
  3. Distinctive:

    Default the body to English (Japanese only when the owner explicitly asks for Japanese).

    line 17
  4. Distinctive:

    Before drafting or revising, read both of these:

    line 18
  5. Very specific:

    When the draft cites eval or LLM measurement numbers, also read and apply llm-evaluation.

    line 21
  6. Distinctive:

    Before asking for review, apply these to any new or substantially revised draft.

    line 22
  7. Very specific:

    Do not add Zenn-style front matter (title / emoji / type / topics, and so on)

    line 37
  8. Distinctive:

    Keep Markdown only; do not turn the draft into a Google Doc

    line 38
  9. Distinctive:

    Do not rewrite existing body text unless the owner explicitly asked for edits

    line 39
  10. Distinctive:

    Write the draft so it can be pasted into LinkedIn's editor as Markdown.

    line 43
  11. Distinctive:

    Do not use tables, HTML, or Mermaid (they break after paste)

    line 45
  12. Very specific:

    Follow english-tech-blog-structure.

    line 53
  13. Distinctive:

    Do not add consulting-style CTAs

    line 69
  14. Distinctive:

    Do not assume readers know proper nouns (for example Ontographia).

    line 74
  15. Very specific:

    Put a few hashtags at the end only (for example #Neo4j #KnowledgeGraph).

    line 76
  16. Distinctive:

    Avoid heavy emoji use, hype, and promises of unconfirmed publish dates

    line 77
  17. Distinctive:

    Do not put version numbers in the title or slug (mention versions in the body if needed)

    line 82
  18. Distinctive:

    Do not exaggerate. State limits, prototype status, and beta where they apply

    line 87
  19. Very specific:

    Use numbers only from measurement logs or public sources.

    line 88
  20. Distinctive:

    Do not promise unconfirmed publish dates

    line 89
  21. Distinctive:

    Do not write as if you verified something you did not verify

    line 90
  22. Distinctive:

    No tables, HTML, or Mermaid

    line 106

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

LinkedIn articles and posts

Generic workflow for drafting and revising English technical LinkedIn articles (long-form / Pulse) and feed posts. Put environment-specific ops—repo paths, which model to use, which worker writes the body—in each assistant's shared rules, not here.

When to use

  • Write or polish a LinkedIn long-form article
  • Write a feed post that announces the same topic
  • Adapt an article from another channel (for example Zenn) into LinkedIn English

English writing rules

  1. Default the body to English (Japanese only when the owner explicitly asks for Japanese).
  2. Before drafting or revising, read both of these:
    • english-tech-blog-structure — structure, headings, titles, closings, technical honesty
    • humanizer — strip sentence-level AI tells
  3. When the draft cites eval or LLM measurement numbers, also read and apply llm-evaluation.
  4. Before asking for review, apply these to any new or substantially revised draft.

File shape

Naming guide:

YYYY-MM-DD-slug-{article|post}.en.md
SuffixRole
-article.en.mdLong-form article body
-post.en.mdFeed post (pair with the same date and slug as the article)
  • Do not add Zenn-style front matter (title / emoji / type / topics, and so on)
  • Keep Markdown only; do not turn the draft into a Google Doc
  • Do not rewrite existing body text unless the owner explicitly asked for edits

LinkedIn editor constraints

Write the draft so it can be pasted into LinkedIn's editor as Markdown.

  • Do not use tables, HTML, or Mermaid (they break after paste)
  • Fenced ``` code blocks in the article body are not auto-converted. When handing the draft to the owner, note that code must be entered with LinkedIn's Code button
  • Feed posts have no code formatting. Keep code in the article; in the post, omit it or use one plain-language line
  • Images can be added in the UI after publish. In the draft, keep diagrams to a minimum as ASCII or plain text
  • Covers and diagrams: load visual-color and visual-diagram.

Long-form article shape

Follow english-tech-blog-structure. LinkedIn-specific extras:

Opening

State the problem or conclusion in the first 2–3 sentences. Do not open with "In this post we will explore…".

Series

  • For a series, put a short series overview near the top (for example a blockquote): part titles, focus, links to earlier/later parts, and links to the main repo or docs
  • Links to unpublished later parts stay as placeholders (for example [LINK TO PART 3]) until those parts ship
  • For a general audience, prefer Releases, docs, and the main repository over links to individual PRs

Headings and closing

  • Headings should name the question the section answers or the object it covers. Avoid bare labels like "Background" or "Conclusion"
  • Close with docs / source / how to try it / a concrete ask for feedback. Do not end by restating the previous summary
  • Do not add consulting-style CTAs

Feed post shape

  • 3–8 short paragraphs. Lead with the article's point, then send readers to the article link for detail
  • Do not assume readers know proper nouns (for example Ontographia). Add a one-line explanation for newcomers
  • End with the article URL (or a placeholder) and the repository URL
  • Put a few hashtags at the end only (for example #Neo4j #KnowledgeGraph). Do not scatter them through the body
  • Avoid heavy emoji use, hype, and promises of unconfirmed publish dates

Titles and slugs

  • Titles should state a concrete claim, story, or payoff. Avoid vague launch phrasing ("Introducing X")
  • Do not put version numbers in the title or slug (mention versions in the body if needed)
  • For a series, Part N in the title is fine

Honesty

  • Do not exaggerate. State limits, prototype status, and beta where they apply
  • Use numbers only from measurement logs or public sources. If it was a single run, say one-run. For eval or LLM measurements, follow llm-evaluation
  • Do not promise unconfirmed publish dates
  • Do not write as if you verified something you did not verify

Typical human publish steps

  1. Review and lock the Markdown
  2. Paste the body into LinkedIn's article editor and fix code blocks by hand
  3. Publish
  4. Post the feed update with the article URL
  5. For a series, update "Upcoming" sections or placeholder links on earlier articles

Agents stop at draft and revision. The owner presses publish.

Success criteria

  • Passed english-tech-blog-structure structure and humanizer checks
  • Filenames match the article / post pattern
  • No tables, HTML, or Mermaid
  • Includes at least one of: trade-offs, measured results, a failure story, or reproduction steps

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free