Describe what you want in words and get a formula, an explanation and test rows.
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.
Schema-grounded SQL
Grounds the query in your real tables, states assumptions and checks for common mistakes.
When to use: Reports from a database, one-off analyses, learning SQL.
Database: [POSTGRESQL / MYSQL / SQL SERVER / SQLITE]
Tables and columns: [PASTE THE SCHEMA OR CREATE TABLE STATEMENTS]
Question: [WHAT YOU WANT TO KNOW, IN PLAIN WORDS]
1. Restate the question precisely: time period, filters, how duplicates and NULLs are handled.
2. Write the query with readable aliases and comments.
3. Check it for common mistakes: wrong JOIN multiplying rows, GROUP BY missing columns, time zones, division by zero, NULL comparisons.
4. Show what the result looks like (column names, 2 example rows).
5. If the query could be slow on large tables, suggest an index.
Only use tables and columns from the schema; if something is missing, ask.