Create LinkedIn posts for AI/tech educational content. Use when the user wants to create a LinkedIn post, repurpose YouTube/long-form content into LinkedIn format, or share AI/tech insights. Triggers on requests like "create a LinkedIn post about...", "turn this into a LinkedIn post", "help me write a LinkedIn post", or any LinkedIn content creation request.
Scanned 9/11/2026
Install to Claude Code
npx -y skills add TheSmokeDev/taskchad-os --skill linkedin-post --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Linkedin Post?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/thesmokedev-linkedin-post)More formats (shields.io, HTML) on the badges page.
---
name: linkedin-post
description: Create LinkedIn posts for AI/tech educational content. Use when the user wants to create a LinkedIn post, repurpose YouTube/long-form content into LinkedIn format, or share AI/tech insights. Triggers on requests like "create a LinkedIn post about...", "turn this into a LinkedIn post", "help me write a LinkedIn post", or any LinkedIn content creation request.
---
# LinkedIn Post Creator
Create LinkedIn posts that sound like you, not like a template.
## Philosophy
**What makes content resonate:**
- **Specificity**: Concrete details that couldn't be templated (dates, numbers, names, tools)
- **Voice**: Your actual way of speaking, not prescribed phrases
- **Genuine intent**: Sharing because you have something to say
- **Earned insight**: Lessons from actual experience, not theory
- **Personal stakes**: Show you're bought in, not just reporting - enthusiasm or skepticism signals you care
**What kills content:**
- Templates and formulas (readers pattern-match instantly)
- Prescribed phrases ("Here's the truth...", "I learned this the hard way...")
- Engagement bait CTAs
- Performative vulnerability (struggle that exists to contrast with success)
- Abstract advice without grounding in real experience
## Content Modes
Instead of templates, start with intent. What are you trying to do?
### Story
You experienced something. You're sharing what happened.
**What makes it work:**
- Starts in a specific moment with real details
- Includes the messy middle, not just failure → success
- Insight emerges naturally from the experience
- Details that couldn't be made up (dates, numbers, what people actually said)
- The experience IS the content, not a vehicle for a predetermined lesson
**What kills it:**
- Hero's journey arc (struggle → triumph → lesson)
- Performative vulnerability (the struggle exists to make current success look better)
- Generic takeaway that could apply to any story
- "And then I realized..." transitions
- Problems that resolve too neatly
### Observation
You noticed something in the industry/world that others might miss.
**What makes it work:**
- Grounded in something specific and real (a product launch, tweet, conversation, data point)
- Your interpretation adds value beyond just reporting what you saw
- Connects dots that aren't obvious
- Can be short - sometimes 3-4 sentences is enough
**What kills it:**
- Obvious observations framed as unique insights
- No actual observation, just setup for your take
- Trend-jumping without adding perspective
- Vague "I've been noticing..." without specifics
### Take
You believe something and want to explain why.
**What makes it work:**
- You actually believe it (not contrarian for engagement)
- You explain your reasoning, not just assert the opinion
- Comes from your experience, not abstract logic
- Acknowledges complexity and where you might be wrong
- Can be short and direct
**What kills it:**
- "Unpopular opinion:" as an opener
- Contrarian positioning without substance
- "Change my mind" or similar closers
- Straw-manning opposing views
- Takes you don't actually hold
### Teach
You know how to do something specific and want to share it.
**What makes it work:**
- You've actually done this thing, recently, in a real context
- Steps are specific and actionable, not abstract frameworks
- Acknowledges edge cases or where it might not work
- Appropriate level of detail (not padded, not too sparse)
- Structure follows content (steps if sequential, paragraphs if not)
**What kills it:**
- Abstract frameworks that sound good but aren't actionable
- Numbered lists for their own sake when content isn't actually sequential
- Teaching things you've only read about, not done
- "5 tips to..." when you really have 2-3 good ones
- Overcomplicating simple things
### React
You're responding to something happening in the world.
**What makes it work:**
- Timely - responding to something recent and relevant
- Adds your perspective beyond just summarizing
- Clear what you're reacting to (link it, quote it, name it)
- Often shorter, more off-the-cuff
- Your angle on the news, not just the news
**What kills it:**
- Hot takes without substance
- Jumping on trends just for visibility
- Summarizing without adding insight
- Being late to something and pretending it's fresh
### Ask
You genuinely want to learn something from your audience.
**What makes it work:**
- You actually don't know the answer
- Question is specific enough to get useful responses
- You'll engage with and learn from the answers
- Can be the entire post: "Question for anyone who's built X: how did you handle Y?"
**What kills it:**
- Rhetorical questions disguised as engagement bait
- Questions you already know the answer to
- Generic "what do you think?" as a closer
- "Curious to hear your thoughts" (you're not that curious)
## Universal Requirements
### Specificity
Every post needs at least 2 concrete details from this list:
- A date or timeframe ("Last March", "three weeks ago", "in 2024")
- A number ("$23K", "6 hours", "14 customers", "3 attempts")
- A name (person, company, tool - with appropriate context)
- A quote (something someone actually said)
- A specific place or context (where it happened, what product, which project)
If you can't include specifics, ask: is this based on real experience or am I abstracting?
**Specificity applies to reasoning too** - don't just state conclusions, explain *why*. "It's peak vibe coding" is weaker than "It's peak vibe coding - you're going with the flow as much as possible for as long as possible." The explanation makes the claim believable.
**Scenario-level specificity matters**: "building frontend with my coding agent" is more grounded than "coding with AI assistance." The narrower context makes it real.
### Experience Attribution
Be clear about what's yours vs. secondhand:
**Own experience:**
- "I tested X and found Y"
- "We deployed this last week and saw Z"
- "I've seen similar results in my work"
**Secondhand with acknowledgment:**
- "Jason Zhou reported X in his testing"
- "According to [source], this shows Y"
- "The research indicates Z"
Readers trust posts where you're clear about your direct experience vs. what you're citing. Don't present others' data as if you ran the test.
### Honest Caveats
Hedging for politeness kills posts. But honest qualification increases credibility.
**Weak hedging (avoid):**
- "It might perhaps be worth considering..."
- "In some cases, this could potentially..."
**Honest qualification (use when true):**
- "It works (sometimes)"
- "In my experience with B2B SaaS..."
- "I haven't tested this outside of [context]"
The difference: weak hedging protects you from being wrong. Honest qualification shows you're not overselling. Readers trust the second one.
### Voice Check
Before posting, ask:
- "Would I say this exact phrase out loud to a colleague?"
- "Does this sound like me or like a LinkedIn post?"
- "Am I using any phrases I've seen in template guides?"
- "Is this how I actually talk about this topic?"
If something sounds "LinkedIn-y," rewrite it in your actual voice.
**Conversational markers are features, not bugs:**
- Parenthetical asides: "(and you should be)", "(at least in my experience)"
- Natural qualifiers: "something like", "generally", "typically", "of course"
- Trailing off: "etc. etc.", "and so on"
- Honest admissions: "too lazy to measure", "haven't gotten around to testing"
These aren't weaknesses - they signal a human is actually thinking while writing, not following a template. They create intimacy and trust.
**Soften technical language naturally:**
When explaining technical topics, use "something like," "generally," "typically" - not to hedge uncertainty, but to maintain conversational tone:
- "The typical approach is something like Playwright's MCP server" (conversational)
- vs "The approach uses Playwright's MCP server" (lecture-y)
- "It generally takes around 4,000 tokens" (human explaining)
- vs "It takes 4,000 tokens" (robot stating)
This isn't weak hedging - it's the difference between lecturing and explaining. You're guiding, not dictating.
### Length
Say what needs to be said. Stop when done.
- Could be 3 sentences or 300 words
- Don't pad to feel substantial
- Don't compress if more detail serves the reader
- Short posts are fine. Long posts are fine. Padded posts aren't.
### Endings
End with a value reveal, not a summary.
Don't conclude or recap what you just said - the reader already knows. Instead, end with a glimpse of what you believe or care about:
**Value-revealing endings:**
- "I'm always a fan of open source tools that can blow my socks off"
- "This is the kind of boring infrastructure that actually matters"
- "I care more about maintainability than generation speed"
**Action-based endings:**
- "Testing this on our staging environment tomorrow"
- "Building a prototype this week to validate"
**Genuine questions (rare):**
- "Has anyone seen this work differently in B2C?"
**Or just stop:**
- Often the best ending is no ending. The link. Period. Done.
**Bad endings:**
- "Agree or disagree?" / "What would you add?" / "Thoughts?" (engagement bait)
- "In conclusion..." / "To summarize..." (unnecessary recap)
- "Check out my [content]" without showing what you value about it
## Anti-Patterns
### Structural Signals (Readers See These Instantly)
- Emoji at beginning and/or end of post
- Perfectly parallel bullet structures (all same length, same rhythm)
- "Broetry" format (single sentence per line, every line)
- Numbered lists when content isn't actually sequential or enumerable
- The → • ✓ symbols used performatively
- Hook + body + CTA structure that's visibly templated
### Rhythm and Cadence Tells
**Em dashes are an LLM giveaway.** Avoid them entirely. Use commas, parentheses, colons, or restructure the sentence. Readers pattern-match em dashes as AI-generated content now.
**Over-punchy staccato rhythm is equally suspicious.** The LinkedIn "power writing" style - very short sentences, lots of periods, two-word fragments - has become so associated with templates and AI that it now signals inauthenticity.
Signs you're being too punchy:
- Multiple two-word sentences in a row ("The results. Mind-blowing.")
- Every sentence is under 10 words
- Three or more fragments stacked for "impact" ("The human touch. The refinement. The decisions.")
- Reads like a series of headlines instead of natural communication
One punchy moment per post is good. It creates emphasis. But if your whole post reads like staccato punches, dial it back. Be concise, but don't confuse punchiness with concision.
**Avoiding all exclamation marks is also a tell.** Total exclamation avoidance has become its own pattern - it signals "I'm trying not to sound like AI." One or two genuine exclamation marks in a post is fine when the content warrants it. Natural enthusiasm isn't cringe. The goal is authentic voice, not performing restraint.
### AI/Template Phrases (Kill These)
- "I'm thrilled/excited to announce"
- "Here's what I learned:"
- "Here's the thing..."
- "The lesson?"
- "Let me break this down"
- "This changed everything"
- "Game-changing"
- "Deep dive"
- "Unpack"
- "At the end of the day"
- "It's not about X, it's about Y"
- Any phrase you've seen in a LinkedIn template guide
**Contrarian hooks are also template phrases now:**
- "Contrarian take:"
- "Unpopular opinion:"
- "Hot take:"
- "Controversial opinion:"
These were fresh in 2020. Now they signal "I'm about to say something mildly disagreeable for engagement." If your take is actually contrarian, you don't need to label it. Just say it.
### Performative Patterns
- Clean failure-to-success arc with tidy resolution
- Vulnerability that exists to contrast with current success
- "I was struggling, but then..." narratives
- Problems that resolve too neatly
- Lessons that are suspiciously clean and universal
- Humble-bragging disguised as story
**Inflated time/effort claims:**
- "I spent weeks researching..." (vague, sounds inflated)
- "After months of work..." (suspiciously grand)
- "Years of experience taught me..." (credential-padding)
Specific, modest timeframes are more believable: "I spent a week testing this" beats "I spent weeks researching this." If you actually spent months, name the months.
### Engagement Bait (Algorithm Detects These)
- "Agree or disagree?"
- "What would you add?"
- "Which one are you trying first?"
- "Comment [KEYWORD] and I'll send you..."
- "Like if you..."
- "Share with someone who..."
- "Tag a friend who..."
- Questions designed to generate comments, not to learn
## Voice Discovery
Don't borrow template phrases. Find your own voice.
**Exercise**: Look at your last 10 messages to colleagues or friends about work topics. Notice:
- How do YOU describe problems when they happen?
- What words do YOU use when you're genuinely excited?
- How do YOU transition between ideas?
- What's YOUR way of admitting you're not sure about something?
- How do YOU tell someone about something interesting you learned?
Those patterns are your voice. Use them. Not the "Here's the truth..." template phrases.
**Test**: Read your post out loud. Does it sound like you talking to a smart colleague? Or does it sound like "a LinkedIn post"? Rewrite until it's the former.
## Source Attribution (For Ideation Workflow)
When posts are generated from content sources, include attribution at the top of the file:
**For digest items:**
```
**Source**: Digest #{number} - {title}
**Original**: {URL from topic file}
**Deep Dive**: {path to topic .md file}
```
**For daily notes:**
```
**Source**: Daily Notes - {IMPORTANT if marked}
**Original**: N/A
**Deep Dive**: {path to daily note file}
```
**For web research:**
```
**Source**: {Article/study title}
**Original**: {specific URL(s) used}
**Deep Dive**: N/A
```
## Formatting Basics
- Short paragraphs (1-2 sentences each)
- Line breaks for readability
- No hashtags
- Links are fine in the post body (one max) - the "first comment only" rule is outdated
- 1,200-1,800 characters is a reasonable range, but length should follow content
- Don't use formatting (bold, symbols) performatively - only when it genuinely aids reading
## Repurposing Long-Form Content
When turning YouTube videos, articles, or other long-form content into LinkedIn posts:
**Do:**
- Extract ONE specific insight, not a summary
- Make the post standalone - it should provide complete value without clicking through
- Add your own take or context
- Link to the full content at the end if relevant
**Don't:**
- Summarize the whole piece
- Write "Just posted a new video about..."
- Make the post a teaser with no standalone value
- Use the post as just a promotional vehicle
The LinkedIn post should be valuable on its own. The long-form content offers depth for those who want more.
**When linking out, be specific about what they'll get:**
Vague: "I recorded a full breakdown (link below)"
Specific: "I just posted a full breakdown on YouTube - how it actually works, where it breaks down, and how to address the gaps (link below)"
The specific version gives people a reason to click. They know what they're getting. The vague version sounds like every other "check out my content" CTA.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!