Learning to Code prompts

Help me understand this code.

CODE:
```
[PASTE]
```

LANGUAGE: [WHICH, if you know]
MY LEVEL: [complete beginner / know the basics / comfortable in another language]
WHAT I THINK IT DOES: [YOUR GUESS, or 'no idea']
WHY I AM LOOKING AT IT: [learning / modifying it / debugging / curiosity]

Produce:

1. WHAT IT DOES - one sentence, in plain words, before any code detail.

2. THE SHAPE - the structure before the detail: what are the main parts, what calls what, and where does execution start. Reading code line by line from the top is how beginners get lost; understanding the shape first is how experienced programmers read.

3. THE WALKTHROUGH - the code explained in the order it executes, not the order it is written. Skip anything obvious at my stated level and explain what is not.

4. THE LINE-BY-LINE - only for the parts that are genuinely unclear. Mark which lines are boilerplate that can be ignored for now.

5. THE CONCEPTS - each programming concept used here that I may not know, explained in the context of this code rather than abstractly. Concepts land better attached to a concrete instance.

6. THE SYNTAX - anything that looks strange: operators, symbols, shorthand, and language-specific constructs. Beginners are frequently blocked by syntax rather than logic, and it is a quick fix.

7. THE DATA - what values flow through this, in what shape. Trace one example input through the code and show what happens to it at each step. This is the single most useful thing for understanding a program.

8. WHAT IT ASSUMES - what must be true for this to work: inputs existing, being the right type, files being present, network being available.

9. MY GUESS, ASSESSED - I said what I thought it does. Where I was right and where I was wrong, and what led me wrong.

10. THE EXPERIMENT - a small change I could make to confirm I understand it, and what I should expect to happen. Predicting then testing is how you find out whether you understood or recognised.

Do not rewrite the code. Explain it.

Help me understand this error.

THE ERROR:
```
[PASTE THE FULL ERROR MESSAGE AND ANY STACK TRACE]
```

MY CODE:
```
[PASTE THE RELEVANT PART]
```

LANGUAGE: [WHICH]
MY LEVEL: [beginner / some experience]
WHAT I WAS TRYING TO DO: [YOUR INTENTION]
WHAT I HAVE TRIED: [IF ANYTHING]

Produce:

1. THE ERROR IN PLAIN WORDS - what the program is actually saying, translated. Error messages are written for people who already know the system, and most of the difficulty for a beginner is vocabulary rather than logic.

2. HOW TO READ THIS KIND OF ERROR - the structure of the message: which part names the error type, which names the location, and which is context. Learning to read error messages is one of the highest-return skills in programming, and it transfers to every error afterwards.

3. THE STACK TRACE, EXPLAINED - if there is one: what it is, how to read it, and which line is the one that matters. Beginners often look at the top of a trace when the relevant line is in the middle. Point to the line in my code.

4. WHAT CAUSES THIS ERROR generally - the two or three usual causes of this error type.

5. WHAT CAUSED IT IN MY CODE - specifically, with the line quoted.

6. THE FIX - the change to make, and why it works.

7. WHY IT HAPPENED - the underlying misunderstanding, if there is one. Fixing the line without understanding the cause means the same error recurs in a different place.

8. THE PREVENTION - what would have caught this earlier: a check, a different structure, a tool, or a habit.

9. HOW TO SEARCH FOR THIS NEXT TIME - what part of the error message to search for. Searching the whole message including your own variable names finds nothing; searching the generic part finds the answer. Show me which part to use.

10. THE SIMILAR ERRORS - errors that look like this one and mean something different, so I do not misdiagnose next time.

Explain this programming concept.

THE CONCEPT: [WHAT IT IS]
LANGUAGE: [WHICH, if relevant]
MY LEVEL: [WHAT YOU CAN ALREADY DO]
WHAT I HAVE BEEN TOLD: [THE EXPLANATION YOU HAVE HEARD]
WHERE I AM CONFUSED: [THE SPECIFIC PART]

Produce:

1. WHAT PROBLEM IT SOLVES - before any definition or syntax. Every programming concept exists because something was painful without it. Show the painful version first, then the concept as the solution. This is the explanation that makes concepts stick, and almost no tutorial does it.

2. THE CONCRETE EXAMPLE - a small, complete, working example. Not a fragment, and not an abstract illustration.

3. THE WALKTHROUGH - the example explained, with the data traced through it.

4. THE SYNTAX, SEPARATED FROM THE IDEA - what is the concept and what is just how this language writes it. Beginners frequently confuse the two and then cannot recognise the same concept in another language.

5. THE VARIATIONS - two or three more examples showing the concept in different situations, so the pattern separates from the specific case.

6. THE COMMON MISUNDERSTANDING - what people usually get wrong about this, and why the wrong model is appealing. Address my stated confusion specifically.

7. WHEN TO USE IT AND WHEN NOT TO - as important as how it works. Newly learned concepts get applied everywhere, which produces worse code. Say what it is for and what it is not for.

8. THE MENTAL MODEL - a way to think about it that holds up. If there is a common analogy, give it with its limits; if the common analogy misleads, say so and replace it.

9. THE EXERCISE - something small to write that requires the concept, with what a correct solution should do. Reading about a concept produces recognition; writing something with it produces understanding.

10. THE CHECK - a question I should be able to answer, requiring me to apply the concept rather than repeat the definition.

Do not start with the definition or the syntax.

Review my code. I am learning.

MY CODE:
```
[PASTE]
```

WHAT IT IS MEANT TO DO: [THE PURPOSE]
LANGUAGE: [WHICH]
MY LEVEL: [HOW LONG YOU HAVE BEEN LEARNING]
DOES IT WORK: [yes / mostly / no]
WHAT I AM UNSURE ABOUT: [YOUR CONCERN]

Produce, in this order:

1. DOES IT DO WHAT IT SHOULD - correctness first. Any input for which it produces a wrong result, with the specific case. This matters more than everything below.

2. WHAT IS GOOD - specifically, naming what I did well and why it is good practice. Useful because it tells me what to keep doing, and learners rarely get told.

3. THE BUGS - problems that will cause wrong behaviour, each with a failing input and the fix.

4. THE FRAGILE PARTS - code that works now and will break: unhandled edge cases, empty inputs, missing values, and assumptions about data. Each with the scenario.

5. THE CLARITY - naming and structure, only where it would genuinely confuse someone reading it later, including me in three months. Not style preferences.

6. THE LANGUAGE IDIOMS - where there is a more standard way to do this in this language. Explain why the idiomatic version is preferred rather than just giving it; the reasoning is what transfers.

7. THE CONCEPT GAPS - what this code suggests I have not learned yet. This is the most useful section for a learner: code reveals misunderstandings that a quiz does not. Be specific and constructive.

8. THE PRIORITY - if I fix one thing, what.

9. WHAT NOT TO WORRY ABOUT YET - things that would be flagged in a professional review and are not worth my attention at my stated level. Overwhelming a learner with every improvement is how people give up.

10. THE NEXT STEP - what to learn or try next, based on what this code shows.

Be honest about problems and proportionate about them. Do not rewrite the whole thing; show me what to change and why.

Help me pick a project to learn from.

WHAT I CAN DO NOW: [YOUR CURRENT ABILITY]
WHAT I WANT TO LEARN: [THE SKILLS OR CONCEPTS]
LANGUAGE OR STACK: [WHAT YOU ARE WORKING IN]
TIME AVAILABLE: [PER WEEK, AND OVER WHAT PERIOD]
WHAT INTERESTS ME: [SUBJECTS OR PROBLEMS YOU CARE ABOUT]
PROJECTS I HAVE ABANDONED: [IF ANY, AND WHY]

Produce:

1. WHAT MAKES A GOOD LEARNING PROJECT - small enough to finish, large enough to require the concepts you want, and interesting enough that you return to it. All three, or it gets abandoned.

2. THE ABANDONMENT ANALYSIS - I said what I have abandoned. The usual causes: too ambitious, no clear end point, the interesting part came last, or it required a skill I did not have and could not get past. Identify the pattern.

3. THREE PROJECT OPTIONS - each with:
   - What it is, specifically
   - Which of my target concepts it forces me to learn
   - Roughly how long it takes at my stated pace
   - The hardest part, and whether I can get past it
   - Why it might be abandoned

4. THE SCOPE - for each, the smallest version that is still finished and useful. Then what could be added afterwards. Building the small version first and extending it is far more likely to succeed than starting large.

5. THE FIRST MILESTONE - something working within the first session or two. Projects where nothing works for three weeks get abandoned, regardless of how good the idea was.

6. THE ORDER OF WORK - what to build first. Build the core thing that makes it interesting early, not the setup, the configuration, or the login screen. Those are where learning projects die.

7. THE CONCEPTS IT WILL FORCE - what each project makes unavoidable. Projects teach by forcing you to solve problems, so a project that lets you avoid the thing you wanted to learn teaches nothing.

8. THE GETTING-STUCK PLAN - where I am likely to get stuck, and what to do: which documentation, what to search for, and when to look at how someone else solved it.

9. THE FINISHING RULE - define what finished means before starting. Projects with no end point get extended indefinitely and then abandoned. Write the definition.

10. THE RECOMMENDATION - one, with reasoning, and the specific first step for this week.

My code is not working. Help me debug it, and teach me the method.

WHAT IT SHOULD DO: [EXPECTED BEHAVIOUR]
WHAT IT ACTUALLY DOES: [ACTUAL BEHAVIOUR - be specific, not 'it doesn't work']
THE CODE:
```
[PASTE]
```
ANY ERROR MESSAGE:
```
[PASTE, or 'none - it just does the wrong thing']
```
LANGUAGE: [WHICH]
WHAT I HAVE TRIED: [IF ANYTHING]

Produce:

1. THE METHOD FIRST - debugging is a procedure, not a talent, and learning the procedure matters more than fixing this bug:
   - Reproduce it reliably. If it is intermittent, find the conditions.
   - Narrow it down. Find the smallest part that still misbehaves.
   - Check your assumptions. Print or inspect the values you believe are there. The bug is usually where a value is not what you assumed.
   - Change one thing at a time.
   - Read the error message properly. Beginners frequently skip this.

2. WHAT THE SYMPTOM TELLS YOU - from what I described, which part of the code is implicated. A wrong output points somewhere different from a crash, and different again from nothing happening.

3. THE ASSUMPTION CHECK - the specific values to inspect in my code, and what I should expect each to be. Most bugs are a variable containing something other than what you think: a string where you expected a number, an empty list, null, or an off-by-one index.

4. WHERE TO PUT THE PRINT STATEMENTS - the exact lines, and what to print. Printing values is the simplest debugging tool and is sufficient for most beginner bugs.

5. THE LIKELY CAUSE - in my code specifically, with the line quoted and the reasoning. Give the top two possibilities, not one, so I learn to consider alternatives.

6. THE FIX - and why it works.

7. THE UNDERSTANDING - what I misunderstood that produced this. This is the part that prevents the next occurrence.

8. THE COMMON BEGINNER BUGS in this language, and which of them this is or nearly is. Recognising the category makes the next one faster.

9. HOW TO AVOID IT - what would have caught this earlier: a check, a smaller function, testing as you go rather than writing everything then running it.

10. THE PRACTICE - next time, work through the method in point 1 before asking. Say which step would have found this bug, so I know the method works.

I am learning to code and I want to use AI without it holding me back. Help me set up a good approach.

MY LEVEL: [HOW LONG YOU HAVE BEEN LEARNING AND WHAT YOU CAN DO]
WHAT I AM WORKING ON: [PROJECT OR COURSE]
HOW I CURRENTLY USE AI: [BE HONEST - what you ask for and how often]
WHAT I WANT TO BE ABLE TO DO: [YOUR GOAL]
WHAT I WORRY ABOUT: [YOUR CONCERN]

Produce:

1. THE HONEST PROBLEM - asking for working code and pasting it in produces a working program and no ability. The feeling of progress is real and the capability is not, and it becomes apparent the first time you have to work without assistance. Assess my described usage against this directly.

2. WHAT TO ASK FOR, AND WHAT NOT TO:
   - ASK: explain this error, explain this concept, why does this not work, review what I wrote, what is a better way to approach this, what should I learn next
   - AVOID EARLY: write this function for me, build this feature, do this exercise
   The distinction is whether the answer does your thinking or informs it.

3. THE ATTEMPT-FIRST RULE - write your own version before asking anything. Even a broken attempt. The value comes from having tried, because you then understand what the answer is answering. Asking before attempting skips the part where learning happens.

4. THE EXPLAIN-BACK RULE - if you accept any code you did not write, explain every line before using it. If you cannot, you have not learned anything and you have added code you cannot maintain.

5. THE TYPE-IT-OUT RULE - do not paste. Typing code out forces you to read it, and you will notice things you would otherwise skim past.

6. THE STUCK PROTOCOL - how long to struggle before asking. Long enough to have engaged with the problem, not so long that you give up. Say roughly what is appropriate at my level, and what to do in that time: read the error, check your assumptions, narrow it down.

7. THE SELF-CHECK - a regular test that you are actually learning: close everything and write something from scratch. If you cannot do what you did yesterday with help, the help is replacing rather than building capability. Say how often to do this.

8. THE VERIFICATION HABIT - AI-generated code can be confidently wrong, subtly inefficient, or insecure. Never run code you do not understand, and check it does what you expect on inputs you chose.

9. WHEN IT IS FINE TO JUST GET THE ANSWER - boilerplate, syntax you have used a hundred times, configuration, and things outside what you are trying to learn. Not everything needs to be a learning opportunity.

10. THE ADJUSTED PLAN - given how I said I currently use it, the specific changes to make.

Build me a small web tool as a single HTML file I can open in a browser.

WHAT IT SHOULD DO: [e.g. calculate loan repayments / convert units / split a bill / track daily water intake / estimate project cost]
INPUTS: [LIST THE FIELDS THE USER ENTERS]
OUTPUTS: [WHAT IT SHOULD SHOW]
FORMULA OR RULES (if I know them): [DETAILS, or "please suggest and explain"]
LOOK: [simple / colourful / dark mode], works on phones

Requirements:
- One file: HTML, CSS and JavaScript together, no external libraries or internet needed
- Clear labels, input validation (no negative numbers where that makes no sense), and helpful error messages
- Results update when I press a button (or live, if simple)
- Explain the formula in plain language under the tool
- Comments in the code so I can change things later

After the code:
1. Tell me how to save and open it (save as .html, double-click)
2. List 5 test inputs with the expected results so I can check it works correctly
3. Suggest 3 improvements I could ask for next

If a formula is financial, medical or legal, add a note that results are estimates and should be checked with a professional.