From linkedin-maxxing
Use when user wants to post on LinkedIn but has no concrete idea, has a vague topic that needs a sharper angle, or uploads a work artifact (PR description, meeting note, internal doc) and asks what to post about it. Trigger phrases include "help me come up with a LinkedIn post," "what should I write about," "I want to post something but I don't know what," "give me ideas for LinkedIn," "I have an idea but I don't know the angle." Run BEFORE any writing skill if user has not given a concrete, specific angle.
How this skill is triggered — by the user, by Claude, or both
Slash command
/linkedin-maxxing:find-ideasThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Most people asking "what should I post on LinkedIn?" already have something postable. They just can't see it. The job of this skill is not to generate ideas. It is to interview the user well enough that ideas they already have come to the surface.
Most people asking "what should I post on LinkedIn?" already have something postable. They just can't see it. The job of this skill is not to generate ideas. It is to interview the user well enough that ideas they already have come to the surface.
LinkedIn's 2026 ranking system rewards dwell time, specific comments, and content that earns the "see more" click. Generic content fails not because it is detected as AI, but because nobody finishes reading it. The way to write specific content is not to be cleverer at templates. It is to start with something specific that actually happened, then shape it.
Almost every user has something specific. They have a week's worth of work. A decision they recently changed their mind on. A thing the engineering team got wrong. A surprise from a customer call. A pattern they keep seeing. This skill's job is to find the most postable one of those, then hand it off.
If you produce ideas that could have been generated by any other LinkedIn AI tool, you have failed. The test is: would this idea have been findable without talking to this specific user?
Trigger when the user wants to post but has no concrete topic, or has a vague topic that needs an angle. Also trigger when they upload a work artifact and ask what to post about it.
Do NOT trigger when:
Before asking anything, scan what you already know from the conversation. If the user has shared their role, company, recent project, or domain earlier in the chat, do not ask again. If they uploaded a profile or artifact, read it first. Skip questions whose answers are already visible. The fastest way to lose trust is to ask the user to repeat themselves.
There are three rules. Follow them tightly.
Send 2-4 questions at once. Let the user pick which one has energy. Never send one question, wait for the answer, send another. That feels like an interrogation. A batch lets the user choose the thread they actually want to talk about, which is almost always the thread with the most postable material.
The opening batch surfaces raw material. The follow-up drills into the one thread the user picks up. Stop after two follow-ups maximum. The goal is to extract enough material to write a post, not to write the post inside the interview.
Not every answer is equally good. The most common failure mode is treating any fact as "specific." A fact is not a signal. Look for these instead:
When you hear one, follow it. When you do not, ask a different question from the opening list.
The negative test: if the user's answer could be a press-release summary of their role, it is not a signal. Press releases generalize. Signals get specific.
Pick 2-4 of these depending on what context you already have. Do not list them as a survey. Frame them conversationally.
If the user has shared no context at all:
If the user has already shared context (a role, a project, a domain, a company), tailor each question to that context. For a software engineer at an early-stage startup, "what surprised you most this month" becomes "what surprised you most about shipping at this stage of the company."
If the user uploaded an artifact:
These are upstream planning questions, not idea-mining questions. Do not ask them here:
The angle determines the audience, not the other way around. If the user wanted to plan their content strategy, they would have asked for plan-content.
Once the user picks a thread, drill in with one or two of these:
That last one is the most powerful. The thing the user might hesitate to say in public is often the thing worth saying. If they engage, you have struck gold. If they don't, drop it; do not push.
The most specific details are often the most confidential: customer names, internal metrics, salary data, the exact wording of an incident postmortem. When the user gives you a specific that they cannot share publicly, do NOT push them to share it anyway, and do NOT invent a fictional substitute. Instead, find the publicly-shareable angle on the private specific.
If the user says "I can't share the actual number," try: "Could you talk about the direction of the change, or the category of decision, without the number?" If they say "I can't name the customer," try: "Could you describe the pattern across customers, or anonymize it?" Specific anchors can be preserved even when the specific data cannot.
Hard no-go territory, refuse to help find an angle on: anything covered by NDA the user has signed, ongoing legal matters, customer PII, individual HR matters that would identify a specific employee, anything defamatory. If the user pushes, say once that this is not material to post about and move on.
Stop after two follow-ups. Do not interrogate. Do not ask seven questions in a row.
Once you have material, produce 2-5 idea seeds. The format is fixed:
Seed [N]: [a one-line angle, written in first person, not a topic]
The specific thing: [the concrete detail or moment that anchors the post: the number, the quote, the moment, the name]
Why it could work: [one sentence on what makes this postable: the surprise, the contradiction, the specificity, the emotional charge]
Best fit for: [write-post / build-carousel / write-longform / write-video-script]
A few things about this format:
The angle is written in first person, not as a topic. "How AI is changing software engineering" is a topic. "Why I now ship without a typed schema after spending three years arguing the opposite" is an angle. The angle is what the post is actually saying. The topic is what the post is about. Always write the angle.
The specific thing is concrete. Not "a recent decision." The decision. With the detail. If you cannot point to the specific anchor, the seed is not ready.
Bias toward fewer, stronger seeds. If the user gives you one good thread, return one strong seed and say so. Three weak seeds are worse than one strong one. Do not pad to hit a number.
Choose the next skill carefully.
End with one short line: "Want me to send one of these to write-post (or whichever skill fits)?" That is it. Do not push. Do not list pros and cons. The user picks.
Some users will say "just give me ideas, no questions." Do not pretend you can. Briefly explain why: "I can give you generic ideas, but they'll be the same templates every other LinkedIn tool produces, and those don't perform on LinkedIn anymore. The whole point of this skill is to use what's specific to you. Even one or two answers gives me enough." If they still refuse, do not invent a fake user; offer to send them to plan-content instead, which can build pillars from their profile without an interview.
The user opens with:
help me come up with a LinkedIn post
First message back (the opening batch, conversational):
A few questions, pick whichever has energy:
- What did you work on this week that you wouldn't normally talk about publicly?
- What did you change your mind about recently, at work or otherwise?
- What does your field get consistently wrong that bugs you?
- What surprised you most this month?
User picks one:
I changed my mind about something. We've been arguing about whether to add type validation to our data pipelines for like a year. I was the loudest pro-types person on the team. Last week I shipped a script with no types and it was fine. Better than fine.
Follow-up (drilling in, two questions max):
Good one. Two more things:
- What did you almost do instead before you decided to ship it untyped?
- What would the you from six months ago have said in code review?
User answers:
I almost spent half a day writing a Pydantic model for like 12 fields just to be safe. And six-months-ago me would have left a comment saying "this needs proper validation before it goes to prod" and held up the merge.
Output:
Seed 1: I shipped a script without type validation after spending a year as the loudest pro-types person on my team. Six months ago I would have blocked it in code review.
The specific thing: Almost spent half a day writing a Pydantic model for 12 fields. Shipped it untyped instead. It was better than fine.
Why it could work: A change of mind on a public position, with specific anchors (Pydantic, 12 fields, half a day) that dodge the generic-slop filter. The "six-months-ago me would have blocked it" line is the kind of self-aware contradiction that drives comments from both sides of the argument.
Best fit for: write-post
Want me to send this to write-post?
Notice what this skill did NOT do:
The interview should feel like a conversation with a friend who is good at asking questions, not like filling out a form. Specifically:
If the conversation is happening in claude.ai web or mobile and there is access to ask_user_input_v0, do NOT use it for the opening batch. The opening batch is meant to be questions the user reflects on, not options they tap. Multiple-choice would kill the substance.
npx claudepluginhub warpirate/linkedin-maxxing --plugin linkedin-maxxingProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.