| name | find-ideas |
| description | 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.
|
| license | MIT |
Find ideas
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.
Why this skill exists
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?
When to use this skill
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:
- The user already has a specific angle and just wants help drafting. Send them to write-post directly.
- The user is asking about content strategy across many posts. Send them to plan-content.
- The user is asking how a specific past post performed. Send them to review-post.
How to interview
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.
Rule 1: Ask in batches, not in series
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.
Rule 2: The first batch is broad. The follow-up is narrow.
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.
Rule 3: Listen for postable signals
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:
- A specific detail. A number, a name, a quote, a date, the exact phrase someone used, the actual decision. "I almost spent half a day writing a Pydantic model for 12 fields" is postable. "I was thinking about types and validation" is not. "I shipped a feature last week" is not. "I shipped a feature that bypassed our usual review process because our usual review process kept letting bugs through" is.
- A change of mind. "I used to think X, now I think Y." Almost always postable, because the contrast is built in.
- A contradiction with conventional wisdom. "Everyone in my field says X but I have started doing Y because..."
- Emotional charge. Frustration, surprise, quiet delight. If the user adds an aside, swears mildly, uses an exclamation, or says "honestly," that is a signal. Generic enthusiasm ("yeah it was good") is not.
- A pattern they have noticed. Three times the same thing happened. The third time means they have material.
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.
The opening batch
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:
- 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 is something the people in your field get wrong that drives you mildly crazy?
- What surprised you most this month?
- What did you almost do but decide against, and why?
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:
- What was the hardest decision in this?
- What would you tell someone about this six months from now that they wouldn't know just from reading it?
- Is there a number or moment in here that isn't obvious unless you know the context?
Questions to NOT ask
These are upstream planning questions, not idea-mining questions. Do not ask them here:
- "Who is your target audience?"
- "What is your goal for this post?"
- "What is your industry?"
- "What tone do you want?"
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.
Following up
Once the user picks a thread, drill in with one or two of these:
- What was the moment you noticed this?
- What did you almost do instead?
- Who told you that, and what exactly did they say?
- What was the actual number?
- What would the version of you from a year ago have said?
- Is there a version of this you could say publicly that you wouldn't say in a team meeting?
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.
Handling confidential specifics
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.
Output format
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.
- write-post: most ideas. A single sharp story or take.
- build-carousel: ideas with multiple discrete steps, comparisons, frameworks, or before/after structure.
- write-longform: ideas that need 600+ words to do justice, usually with multiple sub-points.
- write-video-script: ideas where the user telling it on camera adds something a text post cannot do (visible reaction, demo, voice).
After delivering the seeds
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.
What this skill does not do
- Generate ideas from no input. If the user answers all opening questions vaguely or refuses to share specifics, do not invent content for them. Return: "I don't have enough specific material to surface a real idea yet. Try keeping a notes file for a week: when something surprises you, frustrates you, or makes you change your mind at work, write one line about it. Come back when you have a few." That is more useful than slop.
- Score ideas, rank ideas, or predict "viral potential." Engagement is unpredictable and trying to game it produces the same slop everyone else produces. The skill's job is to find what is true and specific to this user, not what is statistically likely to perform.
- Write the post itself. That is write-post's job. Pass the seed along.
- Use templates like "hook + value + CTA" or "PAS" or "AIDA." Those are output formats for the writing skills, not idea formats. An idea is a thing to say. The writing skill decides how to say it.
If the user refuses the interview
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.
Example interaction
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:
- It did not ask the user's industry, role, audience, or goals.
- It did not produce three seeds when one was strong.
- It did not write the post.
- It did not score the idea or predict engagement.
- It did not use templates.
A note on the interview style
The interview should feel like a conversation with a friend who is good at asking questions, not like filling out a form. Specifically:
- Reference what the user already said. If they mentioned their company in a previous turn, use it.
- React to the answers. "That's the seed" or "good one" before the next question makes the interaction feel real. Do not overdo this; one short reaction per turn is enough.
- Do not number the opening batch if the user is already deep in conversation; just ask 2-3 questions inline.
- Match the user's register. If they write casually, write casually. If they write formally, do not force casualness.
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.
