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
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 GitHubA 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 GitHubA 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 calledorders, 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
orderstoitems."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 GitHubThis page never talks to an AI. It shows runs that were recorded earlier, exactly as the AI wrote them.
Next: Job 2 — Write me a first draft → Use these skills in your own AI tool