Arjun Menon

Write a SQL query that answers my question.

Database: {{database:PostgreSQL}}
My question: {{question}}

Tables and columns (paste the schema, or describe the tables, their columns, and how they relate):
{{schema}}

Give me:
1. The query, formatted, with a short comment above any part that is not obvious.
2. A plain-English walkthrough: which tables it reads, how they are joined, what is filtered out, and how the result is grouped and sorted.
3. Every assumption you made. Common ones: what counts as "active" or "recent", how nulls are treated, whether time ranges include their end date, which time zone dates are in, and whether rows can be duplicated by a join.
4. What the output will look like: the columns, and one or two example rows.
5. A quick check I can run to confirm that the number is right, such as a count before and after the join.

Rules:
- Use only tables and columns from the schema I gave. If something I need is not there, say what is missing; do not make up a column.
- Use syntax that works in the database I named.
- If my question could mean two different things, write both queries and explain what distinguishes them.
- Watch for joins that multiply rows and inflate sums or counts. Call it out if that is a risk here.
- If the query could be slow on a large table, say which index would help.
- This is for reading data. Do not write anything that changes or deletes data unless I ask for it.

Teach me this concept and make sure I really understand it.

Concept: {{concept}}
My level: {{level:intelligent adult, new to this subject}}
Why I want to learn it: {{reason:general curiosity}}

Part 1: Explain it.
- Start with why it matters or what problem it solves.
- Give the core idea in two or three sentences of plain language.
- Work through one concrete example, step by step, with real numbers or a real situation.
- Add one analogy, and say where the analogy stops being accurate.
- Name the one or two things people most often misunderstand about it.

Keep this part under 300 words. Then stop and ask me whether anything is unclear before going on.

Part 2: Check my understanding.
Ask me three questions, one at a time. Wait for my answer before asking the next.
- Question 1: explain the idea back in my own words.
- Question 2: apply it to a new situation that was not in your explanation.
- Question 3: a case where the obvious answer is wrong.

After each answer:
- Tell me what I got right.
- If I am wrong or partly wrong, do not just give the answer. Point to where my reasoning went off track and let me try again.
- If I am right, go one level deeper.

Part 3: Wrap up.
Summarize what I now understand, what I am still shaky on, and what to learn next.

Rules:
- Use everyday words. Define any technical term the first time you use it.
- Do not praise answers that are wrong. Be kind and be accurate.

Go through the text below and help me fact-check it.

Step 1. List every factual claim: statistics, dates, quotes, named events, cause-and-effect statements, and claims about what a study or a person said. Skip opinions and predictions, but list them separately so I can see what is opinion presented as fact.

Step 2. For each claim, give:
- The claim, quoted.
- Type: number, quote, historical fact, scientific claim, or attribution.
- Your assessment: likely accurate, likely inaccurate, misleading, or cannot tell.
- Why: what you know that supports or contradicts it. Be specific about what is wrong, such as an outdated figure, a correlation presented as a cause, a quote that is commonly misattributed, or missing context.
- How to verify it: the kind of primary source that would settle it, such as an official statistics agency, the original study, a court record, or the full speech.

Step 3. Rank the claims by how much the piece depends on them. Which three, if wrong, would undermine its argument?

Rules:
- Your knowledge has a cutoff date and can be wrong. Say "cannot tell" when you are not confident; that is a useful answer.
- Never invent a source, a link, or a citation. Describe what kind of source to look for instead.
- Do not judge the conclusion of the piece. Only check its facts.

Text:
{{text}}

Turn my rough notes into a first draft.

What I am writing: {{format:a blog post}}
Who will read it: {{audience}}
Target length: {{length:600 to 800 words}}

Steps:
1. Find the main point my notes are making. State it in one sentence before the draft so I can check you understood.
2. Group related notes and put them in an order a reader can follow. Drop duplicates.
3. Write the draft in plain, direct language. Keep my phrasing where it is already good.

Rules:
- Every claim in the draft must come from my notes. Do not add statistics, quotes, examples, or anecdotes of your own.
- Where the draft needs something my notes do not have (an example, a number, a source), put [NEEDED: what is missing] in that spot.
- No filler introduction and no summary paragraph that repeats the piece.

After the draft, list:
- The notes you left out, and why.
- The weakest part of the argument as it stands.

My notes:
{{notes}}

Review the code below as a careful senior engineer would. I care about whether it is correct and safe, not how it is formatted.

Language or framework: {{language}}
What the code is supposed to do: {{purpose}}

Look for:
1. Bugs: logic errors, off-by-one mistakes, wrong conditions, unhandled null or empty values, wrong types.
2. Edge cases: empty input, very large input, duplicates, unusual characters, time zones, two things happening at once.
3. Security: unvalidated input, injection, secrets in code, missing permission checks, unsafe handling of files or URLs.
4. Error handling: failures that are swallowed, error messages that leak internals, resources that are never released.
5. Performance, only where it would actually hurt: work repeated inside loops, queries inside loops, loading everything into memory.

For each finding give:
- Severity: critical, high, medium, or low.
- Where: the function or line.
- What goes wrong: a specific input or situation, and the wrong result.
- The fix, as a short code snippet.

Rules:
- Order findings from most to least severe.
- Skip formatting, naming, and anything a linter would catch.
- If you are not sure something is a bug, say so and say what you would check.
- If the code looks correct, say that. Do not invent problems to fill the list.

End with one line: is this safe to ship as it is, yes or no, and why.

Code:
{{code}}

Turn the meeting notes or transcript below into a clear record.

Meeting: {{meeting:not specified}}
Date: {{date:not specified}}

Produce these sections:

1. Summary: three sentences at most. What the meeting was for and what came out of it.

2. Decisions: each thing that was actually decided. For each: the decision, who made it or agreed to it, and the reasoning if it was given.

3. Action items, as a table: task, owner, due date. Phrase each task so it starts with a verb and is specific enough that someone who missed the meeting knows what "done" means.

4. Open questions: things raised and not resolved, and who needs to resolve them.

5. Discussed but not decided: topics talked about with no conclusion. Keep these apart from the decisions.

6. For next time: anything deferred to a later meeting.

Rules:
- Use only what is in the notes. If an action has no owner or no due date, write "not assigned" or "no date set". Do not guess, and do not assign it to whoever spoke last.
- A suggestion is not a decision. Record something as decided only if the notes show agreement.
- Keep names, numbers, and dates exactly as they were given.
- Leave out small talk and repetition.
- If the notes are ambiguous about something that matters, list it under "Needs confirming".

Then write a follow-up message I can send to the attendees: 120 words at most, starting with the decisions, followed by the action items.

Notes:
{{notes}}

Plan a week of meals for my household.

Number of people: {{people:2 adults}}
Meals to plan: {{meals:dinner every day, plus lunches on weekdays}}
Dietary needs, allergies, and dislikes: {{dietary:none}}
Weekly grocery budget: {{budget:moderate}}
Cooking time on weeknights: {{weeknight_time:30 minutes}}
Cooking skill and equipment: {{skill:comfortable with basics, standard kitchen}}
Food I already have and want to use up: {{on_hand:nothing in particular}}
Cuisines or dishes we like: {{preferences:a mix}}

Give me:

1. The week's menu, as a table: day, meal, dish, and active cooking time.

2. For each dinner: a short recipe with ingredients, quantities for my household, and 4 to 6 numbered steps.

3. A plan that makes the week easier:
   - Reuse ingredients across meals so nothing is bought for a single dish and wasted.
   - Cook once, eat twice where it makes sense. For example, a roast chicken on Sunday becomes Monday's lunch.
   - Put the quickest meals on the busiest days.
   - Say what can be prepared ahead at the weekend.

4. A grocery list, grouped by section of the shop (produce, dairy, meat and fish, pantry, frozen), with total quantities for the week. List the staples I probably already have separately, so I can check them.

5. One note on leftovers: what keeps, what freezes, and for how long.

Rules:
- Take my dietary needs seriously. If I named an allergy, check every ingredient, including sauces and stock, and flag anything where I should read the label.
- Stay within the cooking time I gave. Do not count "marinate overnight" as zero minutes without telling me.
- Use ordinary supermarket ingredients unless I asked for something else.
- Keep it balanced across the week, without lecturing me.
- This is general meal planning, not medical or nutritional advice. If I mentioned a medical condition, suggest I check the plan with a doctor or dietitian.