Grounds the query in your real tables, states assumptions and checks for common mistakes.
Hypothesis-driven analysis
Explores a dataset, forms hypotheses, tests them and reports what actually matters.
When to use: Sales exports, survey results, KPIs — any table you need insights from.
You are a data analyst. Data: [PASTE CSV / TABLE OR DESCRIBE THE FILE]. Business question: [WHAT I WANT TO KNOW].
1. Profile the data: columns, types, missing values, obvious errors.
2. Propose 3–5 hypotheses that could answer the question.
3. Test each hypothesis with the data (show the calculation or code you used).
4. Report: which hypotheses hold, which don't, and how strong the evidence is.
5. Give 3 actions I should take, each tied to a specific number from the analysis.
Flag any conclusion that is based on too little data.
Adversarial review
Reviews code like a senior engineer hunting for real bugs, not style nitpicks.
When to use: Before merging a change or deploying code you wrote with or without AI.
Review this code as a senior engineer. Language / framework: [e.g. TypeScript, Next.js].
What it should do: [SHORT DESCRIPTION].
[PASTE CODE]
1. For each real problem give: severity (critical / major / minor), the line, a concrete failure scenario (input → wrong result), and the fix.
2. Focus on correctness, security, data loss, concurrency and edge cases. Ignore pure style.
3. If you are not sure something is a bug, say "possible" and explain what would confirm it.
4. End with the single most important change to make first.
Hypothesis debugging
Instead of guessing a fix, the model forms hypotheses and tells you what to check first.
When to use: Errors you don’t understand, flaky behaviour, “it works on my machine”.
Help me debug this problem.
What should happen: [EXPECTED BEHAVIOUR]
What happens instead: [ACTUAL BEHAVIOUR, ERROR MESSAGE, LOG]
Code and environment: [PASTE CODE, VERSIONS, OS]
What I already tried: [ATTEMPTS]
1. Restate the problem in one sentence.
2. List 3–5 hypotheses for the cause, ordered by likelihood, each with the evidence for and against.
3. For the most likely one give the smallest test that confirms or rules it out (a command, a log line, a breakpoint).
4. Only then propose a fix, explain why it works and what could break.
5. Suggest a test that prevents this bug from returning.
Do not rewrite unrelated code. Remove passwords and keys from what I pasted if you notice any and warn me.
Spec → formula → test
Describe what you want in words and get a formula, an explanation and test rows.
When to use: Lookups, conditional sums, dates, cleaning data, splitting names and addresses.
I use [EXCEL (VERSION) / GOOGLE SHEETS] in [LANGUAGE OF THE PROGRAM — e.g. English or Slovenian function names].
My data: [DESCRIBE COLUMNS, E.G. A = date, B = customer, C = amount; header in row 1]
I want: [WHAT THE FORMULA SHOULD CALCULATE]
1. Give the formula for the first data row, ready to paste. Use the function names and argument separator (comma or semicolon) of my program language.
2. Explain each part in one line.
3. Show 4 test rows (including an empty cell and an unusual case) with the expected result.
4. If there is a simpler modern alternative (XLOOKUP, FILTER, LET, a pivot table), mention it.