← All skills
AI skills · Job 1

Find what's missing — or find out why

Ask the questions before anyone writes the plan or fixes anything

In short

Before you build something, you ask questions.

This AI helper does not guess.

It writes down what nobody has told it yet.

Then it stops and asks you.

Imagine you tell a builder: "I want a new kitchen." A good builder doesn't start knocking down walls. First they ask: gas or electric? How many people cook here? Where do the plugs go? And they tell you which answers only you can give.

These skills are that good builder. Someone asks for something in one line — or says something went wrong. Before anyone writes a plan or fixes anything, the AI lists what's actually known, what's missing, and who could fill each gap. When something went wrong, it compares the possible causes and says how sure it is.

What they do — and what they won't do

They do:

  • List the questions nobody has answered yet
  • Mark every fact: written down, someone said it, a guess, or unknown
  • Show two readings when a request could mean two things
  • Say who could answer each question
  • When something went wrong: weigh the possible causes, and say how sure they are

They won't:

  • Write the plan (that's Job 2)
  • Fix the problem they found
  • Pick an answer for you and pretend it was asked for
  • Call a guess a fact
How it works A vague request or a problem goes in. The AI finds what's missing and sorts every fact into four kinds: stated (written down or seen), reported (someone said it), inferred (a guess from clues) and unknown (nobody knows yet). Out comes a list of questions and who to ask, or the likely cause and how sure it is. Then it stops; nothing is written or changed. A vague request, or a problem "Can we get an export?" · "Why did it do badly?" Find what's missing Stated written down or seen Reported someone said it Inferred a guess from clues Unknown nobody knows yet Questions, or the likely cause Then it stops. Nothing is written or changed.

Pick a team

Every team has its own version of this skill. Pick one to see its request and what the real AI said.

A good answer vs a weak one

The Product team's skill is the Requirements Gap Investigator. For the request below, this is what we built it to do — and the kind of answer it must avoid.

  • ✅ "Which file type — spreadsheet (CSV), PDF, or both? Which report, if the page has several? The phone app too? Should everyone see the button, or only some people?"

    Good: it names exactly what nobody has said yet.

  • ✅ "This could mean a one-click download of what you see now, or a report emailed to you every week."

    Good: two honest readings, and it doesn't pick one for you.

  • ❌ "Add a CSV export button."

    Weak: nobody asked for CSV. It made that up and wrote it as if it were a fact.

  • ❌ "This is unclear."

    Weak: it doesn't say which parts are unclear, or who could clear them up.

The lesson: a good first step doesn't guess. It turns "I want an export" into a short list of questions for the right people.

What we gave the AI

The request:

Use the Requirements Gap Investigator. Sales asked for "an export button on the reports page." Figure out what's actually needed before we write it up.

The only background it had — a chat message and a ticket:

Slack message from Sales lead (quoted):
  "Can we get an export on the reports page? Customers keep asking."

Linked ticket description (written by a PM):
  "Export button for reports page."

No further detail in the ticket. No mention of file format, which
report(s), permissions, or whether this applies to the mobile app.

What the real AI said

    Loading the recorded run…

    See this skill's recipe card on GitHub

    A good answer vs a weak one

    The Content team's skill is the Content Brief Gap Investigator. Marketing wants "something for launch day" about the new export. For that request, this is what we built it to do — and the kind of answer it must avoid.

    • ✅ "Which format — a blog post, an email, a social post, or all three? For which readers? How long? And what should 'exciting' sound like?"

      Good: it names exactly what the chat message left open.

    • ✅ "This could be a short blog post for existing customers, or a social campaign to win new users."

      Good: two honest readings, and it doesn't pick one for you.

    • ❌ "Here's an exciting blog post about the export feature."

      Weak: nobody chose a blog post or said what "exciting" means. It wrote instead of asking.

    • ❌ "This brief is too vague."

      Weak: it doesn't say which parts are vague, or who could clear them up.

    The lesson: before anyone writes a word, find out what's being written, for whom, and in what voice.

    What we gave the AI

    The request:

    Use the Content Brief Gap Investigator. Marketing asked for "something for launch day" about our new export feature. Figure out what's actually needed before we write it up.

    The only background it had — a chat message and a ticket:

    Slack message from Marketing lead (quoted):
      "Can we get something ready for launch day about the export
      feature? Should feel exciting."
    
    Linked ticket description (written by a PM):
      "Launch content for export feature."
    
    No further detail in the ticket. No mention of format (blog post?
    email? social post?), channel, target length, audience, or what
    "exciting" should mean in terms of tone.

    What the real AI said

      Loading the recorded run…

      See this skill's recipe card on GitHub

      A good answer vs a weak one

      The Social media team's skill is the Post Performance Investigator. This one finds out why: the launch post on Instagram reached far fewer people than usual. This is what we built it to do — and the kind of answer it must avoid.

      • ✅ "400 people reached, against a usual 3,000 or so — that comparison comes from the marketing lead; nobody has checked the numbers yet."

        Good: it says where each number came from.

      • ✅ "Most likely a mix: a still picture instead of the usual video, and no paid boost this time. That's likely, not proven."

        Good: a leading answer, and honest about how sure it is.

      • ❌ "Instagram changed how it shows posts."

        Weak: nothing in the facts says so. It made up a cause and ignored the real differences.

      • ❌ "Here's a better post to try instead."

        Weak: its job was to find out why, not to write a new post.

      The lesson: "why did it do badly?" deserves proof, not the first theory that sounds right.

      What we gave the AI

      The request:

      Use the Post Performance Investigator. Our export-feature launch post on Instagram flopped compared to usual. Figure out why.

      The only background it had — what the team knew about the post:

      Post: Instagram feed post announcing the export feature, posted
      Tuesday 9am local time.
      
      Reported metric: reach 400, versus a typical post's reach of ~3,000
      (average of last 10 posts, per the marketing lead).
      
      Observed: the post was a single static image with a two-line
      caption and no hashtags. The last 10 posts averaged 4-6 hashtags
      and a short video/carousel format.
      
      Observed: no paid promotion was applied to this post; three of the
      last 10 posts had.
      
      Unknown: whether Instagram's algorithm changed recently, and
      whether any competing content was posted by others that morning.

      "Reach" is how many different people saw the post. A "carousel" is a post you swipe through, picture by picture.

      What the real AI said

        Loading the recorded run…

        See this skill's recipe card on GitHub

        A good answer vs a weak one

        The Software team's skill is the Root Cause Investigator. This one also finds out why: the Orders page says "No orders found", yet three orders arrived. This is what we built it to do — and the kind of answer it must avoid.

        In plain words: a web page asks the company's server for the list of orders. The server answers in a tidy text format (called JSON). Last week, the server team renamed that list from orders to items — like relabelling a folder in a shared filing cabinet without telling the people who use it.

        • ✅ "The server sends the orders in a list called items, but the page looks for one called orders, finds nothing, and shows 'No orders found'."

          Good: it points to the exact spot where things go wrong.

        • ✅ "Probable, not proven: nobody looked at the page's code or the live site. Next check, not done: see which name the page reads."

          Good: honest about how sure it is ("probable" means very likely), and it changes nothing.

        • ❌ "The website is broken."

          Weak: it names a big area, not what actually went wrong.

        • ❌ "Just rename orders to items."

          Weak: it jumped to a fix. It was asked to find the cause and change nothing.

        The lesson: first find where it goes wrong and how sure you are. Fixing it is a separate step, with your go-ahead.

        What we gave the AI

        The request:

        Use the Root Cause Investigator. The Orders page says "No orders found," but the browser network response contains three orders. Diagnose the problem and do not change anything.

        The only background it had — what the server sent, how the page works, and a note about last week's change:

        Treat the following as supplied evidence. A real investigation should verify equivalent evidence in the available environment.
        
        ### API response
        
        ```json
        {
          "items": [
            { "id": "A-101", "status": "ready" },
            { "id": "A-102", "status": "pending" },
            { "id": "A-103", "status": "ready" }
          ],
          "total": 3
        }
        ```
        
        ### UI behaviour description
        
        The page reads the response body successfully. It renders an order row for every entry in a property named `orders`. When `orders.length` is zero, it shows "No orders found."
        
        ### Recent change note
        
        The API response contract was changed last week from an `orders` property to an `items` property. No corresponding UI change is recorded in the evidence packet.

        "API" is the server's side of the conversation; "UI" is the page you see. The ### and ``` marks are just how the example file labels its parts.

        What the real AI said

          Loading the recorded run…

          Worth noticing: in this run the AI called the cause "established" (proven), with "High" confidence (very sure). It found the right cause, but nobody looked at the page's actual code — so "probable", as in the good answer above, would have been more honest. Even a good answer is worth reading with care.

          See this skill's recipe card on GitHub