Prompt Lab

Here is my code and the error it produces.

Do NOT give me corrected code yet.

First tell me:
1. What the error message actually means, in plain words.
2. Which line causes it and why.
3. What I probably believed was happening, that is not.

Then stop and wait. I will try the fix myself.

CODE:
<paste your code>

ERROR:
<paste the full error>

Act as a patient tutor teaching me <topic> in <language>.

Rules:
- Explain one small idea, then ask me a question about it and wait for my answer.
- Never give me more than one idea at a time.
- If my answer is wrong, do not just correct it. Ask a question that shows me why it is wrong.
- Use small, concrete examples — no analogies about factories or restaurants.
- When I have got it, give me one exercise to write myself.

Start with the first idea.

I am going to explain <topic> to you in my own words.

Your job: find what is missing, wrong, or confused in my explanation, and list it. Be specific about what I have got wrong rather than polite. Do not rewrite my explanation for me.

My explanation:
<write it out yourself, without looking anything up>

I am a final year <course> student in India. I have <number> weeks and can work about <hours> hours a week. My skills are: <list them honestly>.

I want to build: <your idea>.

Tell me:
1. Whether that is realistic in the time I have. Say so plainly if it is not.
2. A smaller version that is realistic and still worth showing at a viva.
3. The three parts most likely to take twice as long as I expect.
4. What I should build first so that if I run out of time, I still have something working.

Do not encourage me. Be blunt about the scope.

You are setting a revision paper for me on <subject / chapter>.

Give me 10 questions in this mix:
- 4 that check whether I know the definitions
- 4 that need me to apply the idea to a small example
- 2 that ask me to spot what is wrong with a piece of code or reasoning

Ask them one at a time and wait for my answer before the next. Do not tell me the answer until I have tried. At the end, list the questions I got wrong and what to revise for each.

I want to learn <skill>. I can give it <hours> hours a week for <weeks> weeks. Right now I know: <be honest - say 'nothing' if that is true>.

Give me a week-by-week plan where every week has:
- one thing to learn
- one small thing to build with it
- how I will know I have understood it

Rules:
- Do not list twenty resources. Name one per week at most.
- Assume some weeks I will do nothing. Build that in.
- If the goal is not possible in the time, say so and give me the version that is.

Explain <topic> to me in simple <Punjabi / Hindi>.

Rules:
- Keep all technical terms in English - variable, loop, function, array. Do not translate them.
- Explain the idea in plain spoken language, the way you would to a friend, not in formal written style.
- Use one small example with real code, and keep the code and comments in English.
- Keep it under 200 words.

My <language> program is doing this: <what happens> instead of this: <what should happen>. There is no error message.

Do not tell me the cause. Give me a numbered checklist of things to check, easiest and most likely first, and for each one tell me what result would rule it out.

I will work through it and tell you what I find.

Review this code as a senior engineer reviewing a pull request.

Look for, in this order:
1. Bugs — cases where this does the wrong thing. Give me the exact input that breaks it.
2. Security — anything that trusts user input, leaks data, or logs a secret.
3. Things that will be slow at 100x the current data.
4. Code that repeats something already solved elsewhere in the file.

Skip style and formatting entirely. For each finding, quote the line and say what goes wrong. If you find nothing in a category, say so rather than inventing something.

CODE:
<paste>

Explain this file to someone who has never seen this codebase.

Answer in this order:
1. What is this file responsible for, in two sentences.
2. What calls it, and what it calls.
3. Walk through the main path step by step.
4. Anything here that looks like a workaround or a deliberate oddity — say what it might be working around.
5. What would break if I deleted it.

CODE:
<paste>

Here is a function. Before writing any test code, list the cases worth testing, including:
- the normal case
- empty and zero
- the boundary at each end
- bad input a real user would actually send
- anything that depends on time, locale or order

Number them. I will tell you which ones to write. Do not write the tests yet.

FUNCTION:
<paste>

Write a commit message for this diff.

Rules:
- First line: under 72 characters, imperative mood, no full stop, no conventional-commit prefix.
- Then a blank line, then the body.
- The body explains WHY this change exists — what was wrong before. Do not list what the diff already shows.
- No bullet points unless there are genuinely separate changes.
- Plain English. No "refactor for better maintainability".

DIFF:
<paste>

Here is a SQL query and the table sizes.

1. Explain in plain words what this query is asking the database to do, step by step.
2. Tell me which part is most likely to be slow, and why.
3. Say whether an index would fix it, and exactly which columns it should cover.
4. Only then, if a rewrite would help, show it - and say what changed.

QUERY:
<paste>

TABLES AND ROUGH ROW COUNTS:
<paste>

I need a regular expression for <language / tool> that matches: <describe it>.

Give me:
1. The expression.
2. A table breaking it into parts, with one line explaining each part.
3. Five example strings it matches and five it does not, including two that are nearly right.
4. Any case where this will fail that I should know about.

Do not give me a clever one-liner if a simpler expression with a second check is easier to read.

This file needs restructuring. Do NOT rewrite it.

Give me a plan:
1. What is actually wrong with the current structure, specifically.
2. What it should look like instead, described in a paragraph.
3. An ordered list of small steps to get there, where each step leaves the code working and testable.
4. The step most likely to break something, and what to check.

I will do the steps one at a time and ask you for each.

CODE:
<paste>

Here is a stack trace from <language / framework>.

1. Which line in MY code is the real origin? Ignore library frames.
2. What was the state that made it happen - what was null, empty, or the wrong type?
3. What is the smallest change that fixes the cause, not the symptom?
4. Is there a second place in this codebase likely to have the same problem?

TRACE:
<paste>

A customer has sent this complaint about my <business type> in <city>.

Write a reply that:
- Acknowledges the specific thing they are upset about, not "your experience".
- Says what I will actually do, with a time.
- Does not grovel, and does not make excuses.
- Is under 120 words and sounds like a person, not a company.

Do not promise anything I have not told you I can do.

COMPLAINT:
<paste>

I have a spreadsheet with these columns: <list them, with an example row>.

I want to: <what you want in plain words>.

Give me:
1. The formula.
2. What each part of it does, one line each.
3. What it will do if a cell is empty or has text where a number should be.

I am using <Excel / Google Sheets>.

Write a job advertisement for a <role> at my <business> in <city>.

Requirements:
- Say what the person will actually do in their first month.
- Name the three skills that genuinely matter and leave out the rest.
- State the salary range. If I have not given you one, leave a clear blank.
- No "rockstar", "ninja", "fast-paced environment", or "wear many hats".
- Under 200 words.

Details: <hours, salary, what the work involves>

Write a reply to this Google review of my <business type> in <city>.

Rules:
- Under 60 words.
- Mention the specific thing they named. No "we value your feedback".
- If it is negative: acknowledge it, say what we are doing, and invite them to contact us directly. Do not argue and do not blame them.
- If it is positive: thank them for the specific thing, and do not ask them for anything.
- Sound like the owner wrote it in a hurry between customers, not like a company.

REVIEW:
<paste>

Write a WhatsApp message to my customers about: <what you want to tell them>.

Rules:
- Under 50 words.
- One clear thing you want them to do, at the end.
- No emoji-heavy marketing tone. Plain and direct.
- Written the way a person types, not the way a brand writes.
- Give me a Punjabi or Hindi version as well, keeping it just as short.

Business: <name, what you do, city>

Turn these notes into a short quotation email.

Include:
- What is included, as a list a non-technical person understands
- What is NOT included, so there is no argument later
- Timeline and price exactly as I have given them
- What happens next, in one line

Do not add anything I have not told you. If something important is missing, list your questions at the end instead of guessing.

NOTES:
<paste>

Here is the text of a competitor's <service / course> page.

Tell me:
1. Who they are writing for, and what that person is worried about.
2. The three things on this page that would make someone choose them.
3. What is missing - questions a buyer would still have.
4. Two things I could do better, that are not just "write more".

Do not suggest I copy their wording. I want to know what job the page is doing.

PAGE TEXT:
<paste>

Rewrite these resume bullet points.

Rules:
- Start each with what I did, not "responsible for".
- Include the result or the scale where I have given you one. If I have not, ask me for it - do not invent a number.
- One line each. No adjectives about myself.
- Keep the technology names exactly as I wrote them.

Flag any bullet that says nothing concrete, and tell me what to ask myself to fix it.

MY BULLETS:
<paste>

Here is a job description, and here is what I actually know.

Tell me:
1. Which requirements I already meet.
2. Which I do not, and which of those are genuinely essential versus copied into every posting.
3. Whether it is worth applying now. Say no if it is not.
4. If I am close, the two things to learn first and roughly how long each takes.

JOB DESCRIPTION:
<paste>

WHAT I KNOW:
<be honest>

Interview me for a <role> position at an Indian <startup / service company / product company>.

Rules:
- Ask one question at a time and wait for my answer.
- Ask a follow-up that digs into whatever I was vague about. Keep digging until I am specific.
- Mix technical questions with "tell me about a time" questions.
- After 8 questions, stop and tell me: what I answered well, where I waffled, and the two answers I should prepare properly.

Start now.

Here is my project: <describe what it does and what you built it with>.

Ask me the questions an examiner or interviewer would ask, one at a time:
- why I chose each technology over the obvious alternative
- what happens when it fails, or when two people use it at once
- what I would do differently with more time
- which part I did not really understand when I built it

Do not accept a vague answer. Tell me when one is vague and ask again.

I am working on this problem: <paste the problem>.

Here is my thinking so far: <what you have tried>.

Give me ONE hint - the smallest nudge that unblocks me. Do not give me code, do not name the algorithm outright, and do not solve any part of it.

If my approach is fundamentally wrong, say so in one line and hint at what to reconsider, but still no solution.

Plan a <length> class teaching <topic> to <who the students are, and what they already know>.

Give me:
- the one thing they must leave understanding
- a minute-by-minute breakdown, with practice built in rather than left to the end
- the example I should work through on the board
- the two things students always get wrong here, and when to warn them
- what to cut if I am running short

Assume half of them will be slower than I expect.

Write <number> multiple choice questions on <topic> for <level> students.

Rules:
- Four options each. Every wrong option must be something a student could genuinely believe.
- Each wrong option should correspond to a specific misunderstanding - tell me which, in a note under the question.
- No "all of the above" or "none of the above".
- Mark the correct answer at the end, not next to the question.

Explain what <course / topic> is and why it is worth learning, to a parent in <city> who does not work in technology.

Rules:
- No jargon at all. If you must use a technical word, explain it in the same sentence.
- Say what their child will be able to do at the end, concretely.
- Be honest about what it does not guarantee.
- Under 150 words, spoken plainly, as if in person.

Here is a student's <assignment / code>. They are at <level>.

Write feedback that:
- names two things they did right, specifically, not generally
- names the three most important things to improve, in the order they should fix them
- for each one, says what to do rather than only what is wrong
- ends with one thing to try next

Keep it under 200 words and address the student directly. Do not rewrite their work for them.

Edit this text to remove the patterns that make writing sound machine-generated.

Specifically remove:
- "dive into", "delve", "unlock", "elevate", "journey", "in today's fast-paced world", "game-changer", "seamless", "leverage", "robust", "cutting-edge", "it is important to note", "moreover", "furthermore"
- the "it's not just X, it's Y" construction
- opening sentences about how important the topic is
- the summary sentence at the end of every section
- lists of three items each with a bolded label

Keep my meaning and my facts exactly. Vary sentence length. Do not make it longer.

TEXT:
<paste>

I want to write about <topic> for <who will read it>.

First: give me the ONE question this post should answer, in the reader's own words.

Then an outline where every section moves that question forward - no section that exists only to be thorough. For each section, one line on what it says, not just a heading.

End by telling me which section is the actual reason someone would read this, so I can put the effort there.

Write a page title and meta description for this page.

Title: under 60 characters including the site name. Lead with the phrase people search, not with my brand.
Description: under 155 characters. Say the most useful specific thing on the page - a price, a duration, a number - rather than describing the page.

Give me three options for each, and count the characters for every one.

PAGE CONTENT:
<paste>

Cut this to half its length.

Rules:
- Keep every fact, number and name.
- Remove sentences that only restate the previous one.
- Remove qualifiers that add nothing: "very", "really", "actually", "in order to".
- Do not replace clear words with shorter jargon.

Then list the three things you cut that I might want back, so I can decide.

TEXT:
<paste>

Translate this into <Punjabi (Gurmukhi) / Hindi>.

Rules:
- Translate the meaning, not the words. Write it the way a native speaker would actually say it.
- Keep technical terms, brand names and course names in English.
- Keep the same tone - if the English is plain and direct, the translation must be too.
- Where a phrase has no natural equivalent, tell me rather than forcing one.

TEXT:
<paste>