/find-ideas

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?"