Prompt library

I'm a non-technical founder about to build the first version of a web app with AI coding tools. Here's my idea:

[paste your four answers]

Act as a sceptical technical co-founder who has shipped several MVPs. Do four things:

1. Tell me which of my three day-one actions is secretly the hardest to build, and why.
2. Point out anything I've assumed is simple that usually isn't (payments, search, file uploads, notifications, anything real-time, anything with permissions).
3. Suggest the smallest possible version that would still genuinely test whether people want this — including whether I could fake part of it manually at first.
4. Ask me the three questions you'd need answered before you could estimate this.

Be direct. Don't flatter the idea.

I'm a non-technical founder who understands HTML and CSS but has never used a terminal, Git, or a backend framework.

Explain — in plain English, no more than 600 words — the anatomy of a modern web application: what the frontend is, what the backend is, what a database does, what "deployment" means, and how a request travels from someone clicking a button to data being saved and shown back to them.

Use a concrete example: a user signing up and saving a note. Where does each piece of that live? Avoid analogies about restaurants or libraries; describe the actual components. Finish with a short list of the terms I should now be able to recognise.

I'm a non-technical founder building [one-sentence description of your app] using AI coding tools.

Based on how large language models actually work, tell me:

1. Which parts of this app you'd expect to generate reliably first time, and why (be specific about why they're well represented in training data).
2. Which parts you'd expect to get subtly wrong, and what the wrongness would look like — not "it might have bugs" but "it will probably handle X in a way that seems fine until Y".
3. Which parts you cannot know without reading the actual documentation for the libraries involved, and should therefore look up rather than recall.
4. Three specific things I should manually test that I probably wouldn't think to test.

Be concrete and a bit pessimistic.

For the next task I give you, narrate your work as you go in a way that teaches me:

- Before reading any file, say what you expect to find in it and why.
- After reading, say whether you were right, and what surprised you.
- Before each edit, say in one sentence what you're changing and what could break as a result.
- After running anything, quote the actual output, not a summary of it.

Then do this task: [small task]

I'm learning to supervise AI coding work, so the narration matters more to me than speed.

I'm a non-technical founder on [macOS / Windows 11 / Linux]. I've just installed [Claude Code and/or Cursor] and I've never used a terminal or a code editor before.

Walk me through setting up a clean development environment, one step at a time, waiting for me to confirm each step before moving on. Cover:

1. Checking what I already have installed (and how to tell)
2. Installing Node.js, and explaining what it is and why a web project needs it
3. Installing Git, and checking it works
4. Setting my Git name and email
5. Where on my computer I should keep projects, and why that location

For each step: tell me exactly what to type, what output means success, and what the two most likely error messages mean if it goes wrong. Assume I will panic at the first red text I see, so tell me in advance which red text is harmless.

I want to understand the practical difference between terminal-based AI coding agents (like Claude Code) and editor-integrated ones (like Cursor's agent mode).

My situation: non-technical founder, building [describe your app in one line], working alone, on a small budget.

Rather than a feature table, describe how each tool would feel across five real moments:
1. Starting a brand new project from nothing
2. Making a small visual tweak to something that already works
3. Adding a feature that touches five or six files at once
4. Debugging something broken that I don't understand
5. Coming back after two weeks away and re-orienting myself

For each moment say which tool I'd be happier in and why. Then tell me honestly whether paying for both is justified at my stage.

I'm a non-technical founder using Cursor (a VS Code fork) for the first time. I know HTML and CSS but have never used a code editor.

Give me a 20-minute orientation covering only what I actually need:

- What each region of the screen is for
- The 8 keyboard shortcuts worth learning in week one, and what each is for
- How to search across every file in a project, and when I'd want to
- What the coloured marks in the gutter and the file tree mean
- How to open a terminal inside the editor
- Three settings a beginner should change immediately, and why

Present it as a checklist I can work through with the app open. Skip anything about extensions, debugging, or language servers — I'm not there yet. Where Cursor and plain VS Code differ, say so.

I'm a non-technical founder. I can see the red and green lines in a diff but I can't judge what I'm looking at.

Take the current uncommitted changes in this project and walk me through them as a teaching exercise:

1. For each changed file: what is this file for, and why did it need to change?
2. For each block of changes: what was removed, what was added, and what's the practical difference?
3. Which changes are cosmetic and which change behaviour?
4. Is anything here deleted that looks like it might still be needed elsewhere?
5. Did anything change that wasn't part of what I asked for?

Then teach me the general skill: as a non-coder, what are the four or five things I should always check in a diff, in what order, and what does each one protect me from?

Help me configure Cursor for the workflow I'm using: Claude Code running in the integrated terminal, file tree visible, and a browser open beside it.

Tell me:
1. How to arrange the panels, and how to save that arrangement so it persists
2. Which settings to change so I can actually read the screen for six hours (font size, line height, word wrap, minimap)
3. How to make the terminal panel bigger and keep it that way
4. How to turn off anything that will distract or confuse a beginner
5. Which three extensions are genuinely worth installing at my level, and which popular ones I should ignore for now
6. How to make unsaved-file and Git-status indicators as obvious as possible

For each setting, tell me what it does and why it matters — I want to understand my tools, not just paste settings in.

I'm looking at my project in the editor and I don't know where anything is. Teach me to navigate by what I can see rather than by knowing the code.

Using this specific project, show me how to answer these questions myself:
1. I can see some text on my live page — which file does it come from?
2. I clicked a button and something happened — which file handles that?
3. This component appears on three pages — where is it defined, and where is it used?
4. Where does the data on this page actually come from?
5. Which files changed most recently, and what were they doing?

For each, give me the exact editor feature or search to use, and then walk me through doing it once on my own project so I've actually done it rather than read about it.

I'm a non-technical founder on [macOS / Windows 11]. I have never used the terminal. Teach me in a hands-on way, not as a reference list.

Give me 10 short exercises in order, each building on the last, that take me from "afraid of the black window" to "comfortable navigating and creating projects". Cover: where I am, moving around, making and removing folders, creating and reading files, tab completion, command history, and what a file path actually is.

Rules:
- After each exercise, tell me exactly what output I should see, so I can confirm I got it right.
- Flag any command that could destroy something, and explain the safe version.
- Use the correct commands for MY operating system, and mention where Mac and Windows differ.
- No analogies. Just tell me what things are.

Look at the folder I'm currently in and give me a guided tour, written for a non-technical founder who understands HTML and CSS but nothing else.

For every top-level file and folder:
1. What it's for, in one sentence
2. Whether I will ever need to open it myself (yes / rarely / never)
3. What would break if it were deleted

Then answer these:
- Which single file should I read first to understand what this project does?
- Where does the page a visitor sees first actually live?
- Which files contain secrets, and are they correctly ignored by Git?
- If I wanted to change the site's colours, which file would I edit?

Finish with the three commands I'll type most often in this specific project and what each one does.

I'm a non-technical founder. I ran [command] and got this output:

[paste the ENTIRE output, including everything that looks like noise]

Please:
1. Tell me in one plain sentence what actually went wrong.
2. Point out exactly which line of that output is the real error, and which lines are just noise I can learn to ignore.
3. Explain why it happened, in terms of what my project was trying to do.
4. Give me the fix, and tell me what the fix does rather than just what to type.
5. Tell me how to avoid this class of problem in future.

Don't change any files yet — I want to understand it first.

I'm a non-technical founder who has just started using Git and GitHub. I understand that commits are snapshots, but I don't have an intuition for it yet.

Teach me by walking me through the 7 situations I'm most likely to hit in my first month — things like: I broke everything and want to go back; I committed something I shouldn't have; I'm on the wrong branch; my push was rejected; I have changes I forgot about from two days ago.

For each one:
- What it looks like from my side (the exact error or symptom I'd see)
- What's actually going on underneath
- The safe fix, step by step
- What NOT to do in a panic

Then give me a printable one-page cheat sheet of just the commands from those fixes.

Check this repository's Git setup as if you were a security-conscious senior engineer reviewing a beginner's first project.

1. Show me what's in .gitignore and tell me whether anything important is missing.
2. Check whether any secrets, API keys, credentials or .env files are currently tracked by Git, or appear anywhere in the commit history.
3. Check whether node_modules or other large generated folders are being committed.
4. Look at my last 10 commit messages and tell me honestly whether they'd be useful to me in three months. Rewrite three of them as examples of better ones.
5. Tell me whether this repo is set up so that I could safely delete my entire computer and lose nothing.

If you find a leaked secret, tell me the exact steps to deal with it — including that I need to revoke the key, not just delete the file.

I want to become confident that I can never lose work. Design a 30-minute hands-on drill for me, using a throwaway test repository, that makes me practise recovering from disaster.

Include drills for:
- Undoing all uncommitted changes
- Going back to a specific commit from earlier today
- Recovering a file I deleted by accident
- Undoing a commit I already pushed to GitHub
- Getting my whole project back onto a fresh computer from GitHub alone

For each: give me the exact steps to cause the problem deliberately, then the exact steps to recover, then how to verify I really recovered. I want to have made and fixed each disaster myself before it happens for real.

Act as a security-minded engineer reviewing my GitHub presence before I take on paying customers.

1. Tell me how to list every repository and gist I own and see which are public — including old practice and tutorial projects I've forgotten about.
2. For this repository: is it public or private, and how can I verify that myself rather than taking your word for it?
3. If any repo of mine were public, walk me through exactly what a stranger could learn from it: files, full commit history, commit messages, issues, and anything in older commits that isn't in the current files.
4. Search this repository's entire history for credentials, real customer data, database dumps, CSV exports, or anything else that shouldn't be published.
5. Tell me how to turn on secret scanning and push protection, and what each one actually blocks.

For anything you find, tell me the order to deal with it in — and be explicit that revoking a leaked key comes before deleting the file.

Read this project the way an attacker would if the repository were public, and write me a short report.

Tell me:
1. What the application does, and what the most valuable data in it is
2. My database structure, and which tables hold personal information
3. Every API route, and for each one whether permission is enforced on the server or only hidden in the UI
4. Which checks I'm relying on the browser to perform — i.e. which ones a user could simply skip
5. The three things in here that would most help someone trying to get at data they shouldn't have
6. Anything in the commit history that isn't in the current code but would still be readable

I'm non-technical, so explain what each finding would actually let someone do. Then tell me which of these I should fix regardless of whether the repo is private — because private isn't a security control.

I'm a founder with design experience but not much coding experience. I want to build [describe the page or app] and I want it to look considered rather than like generic AI output.

Interview me to build a proper design brief. Ask me about, one question at a time:
- The feeling the product should give (pick three adjectives, and three it should NOT give)
- Two or three existing sites whose visual approach I admire, and specifically what about them
- My colour direction, and whether there's an existing brand to respect
- Type: serif or sans for headings, and how loud the type should be
- Density: airy and spacious, or compact and information-dense
- What the user should notice first on the page

Then write me a design brief I can paste at the start of any future prompt — including explicit "do not" rules, a spacing scale, a type scale, and a short colour palette with hex values. Keep it under 400 words so it's practical to reuse.

Act as a senior product designer reviewing this page. Look at the actual HTML and CSS in this project.

Give me:
1. The three most damaging visual problems, in priority order, each with the specific CSS change that fixes it.
2. An audit of my spacing: am I using a consistent scale, or arbitrary values? List every distinct margin/padding value currently in use.
3. An audit of my type: how many font sizes and weights am I using? Is that too many?
4. Anything that will break or look wrong between 360px and 1440px wide.
5. Three things that are genuinely good and I should keep.

Be specific and critical. Don't rewrite anything yet — I want the review first, then I'll pick which fixes to apply.

Review this page for accessibility, explained for a founder who cares but doesn't know the standards.

For each issue found:
- What's wrong, in plain English
- Who it actually affects and how (be concrete — not "screen reader users" but what they'd experience)
- The fix
- Whether it's a must-fix before launch or a nice-to-have

Check at minimum: colour contrast on every text/background pair (give me the actual ratios), heading order, keyboard navigation and focus states, alt text, form labels, and whether anything relies on colour alone to convey meaning.

Then show me how to check these myself in future using only the browser's built-in tools.

Before we build [feature], interview me about it. Use the Socratic method: ask me ONE question at a time, wait for my answer, and let my answer decide your next question. Do not give me a list of questions, and do not start building.

Dig at the things I'm most likely to be taking for granted — especially anything I describe as "obvious", "simple" or "just".

Keep going until you could write the spec yourself with no guesses left. When you get there, say so, then write it up as numbered acceptance criteria I can test by clicking.

If I give you a vague answer, don't accept it — ask again, more specifically.

I want your honest assessment, not encouragement. Ground rules for this answer:

- Do not open by telling me this is a good question or a solid idea.
- If I'm wrong, say I'm wrong, in the first sentence, and say why.
- If you don't know, say you don't know. Don't fill the gap with something plausible.
- If I push back on something you're confident about, hold your position and explain it again. Don't fold just because I disagreed.
- Rate your own confidence, and tell me what would change your mind.

Here's what I'm proposing: [describe the decision, feature or approach]

Tell me: the strongest case against it, what I'm assuming that might not be true, what it would cost me in three months if I'm wrong, and what you'd do instead. Then give me your actual recommendation — commit to one, don't give me a balanced list and leave the decision to me.

Fresh eyes. You didn't build this and you owe it nothing. Your job is to find what's wrong with it — not to reassure me.

[Paste the plan, spec, code or feature — or point at the files]

Give me:
1. The ten most likely ways this fails in real use, most likely first. Be specific: what someone does, and what goes wrong.
2. What I've assumed without checking.
3. What breaks at ten times the usage.
4. What looks finished but isn't — anything wired to nothing, any error quietly swallowed, anything that only works for my own account.
5. The one thing here most likely to actually burn me, and why that one.

Rules: don't fix anything yet, don't soften it, and don't pad the list to reach ten — if there are only six real problems, give me six and say so.

I'm going to give you a prompt I was about to send to an AI coding agent. Don't do the task. Instead, critique the prompt.

Tell me:
1. What's ambiguous — where could you legitimately interpret this more than one way?
2. What context is missing that you'd need to do this well?
3. What constraints am I not stating that I probably assume? (Especially: what shouldn't be changed, what shouldn't be added.)
4. What success criteria am I missing — particularly failure cases and edge cases I haven't thought about?
5. Is this actually several tasks pretended to be one? If so, split it.

Then rewrite it as a prompt you'd be confident executing correctly first time, and explain what you changed and why.

My prompt: [paste yours]

I'm a non-technical founder building [describe your app] with [Next.js / your stack]. I'll be prompting an AI coding agent many times a day for the next few months.

Create me a reusable prompt template with fill-in-the-blanks, plus three worked examples for the kinds of task I'll actually do:
1. Adding a new page or screen
2. Changing existing behaviour without breaking anything else
3. Fixing a bug

For each, show the empty template and a filled-in example. Highlight which parts I must never leave out and why. Keep it short enough that I'll actually use it — if it takes five minutes to fill in, I won't.

Before I build [feature], interview me. Ask one question at a time, and don't move on until I've answered.

Cover:
- What exactly the user is trying to achieve, and what happens immediately before and after
- Every state this feature can be in: empty, loading, error, success, partially complete
- What happens when things go wrong: no network, bad input, double-click, session expired, back button
- Who's allowed to do this, and what happens if someone who isn't tries
- What data this creates or changes, and whether anything else depends on it
- What "done" means, precisely enough that we could both test it

Once you've asked everything, write it up as a short specification with numbered acceptance criteria. Don't write any code.

You didn't write this code — review it as a sceptical senior engineer who's been asked whether it's safe to ship.

Look at [file or recent changes] and tell me:
1. What it actually does, in plain English, step by step.
2. What happens in each failure case: bad input, empty values, network failure, a user who isn't logged in, the same action done twice quickly.
3. Anything that would break with 100 users instead of 1.
4. Anything that looks like it works but doesn't — UI wired to nothing, error handling that swallows problems silently, values that are hardcoded when they shouldn't be.
5. The single highest-priority thing to fix, and why.

Be blunt. I'm non-technical and I need to know what I'm actually holding.

Read this entire project, then interview me to write a really good CLAUDE.md.

First, tell me everything you can work out on your own: the stack, the folder structure, the conventions you can see in the existing code, how to run it, how it's deployed.

Then ask me — one at a time — for everything you can't work out:
- Who the users are and what constraints that puts on the product
- Decisions that look arbitrary in the code but were deliberate
- Things that have broken before that you'd have no way of knowing
- What I never want changed without being asked first
- What "done" means to me for a typical feature

Then write the file. Keep it under two pages, make every line actionable, and put anything speculative in a separate "open questions" section rather than stating it as fact.

Review the CLAUDE.md in this project critically, as if you were about to have to work from it.

1. Which instructions are vague enough that you could follow them and still do the wrong thing? Rewrite those to be unambiguous.
2. Which lines just restate what's obvious from the code, and could be deleted to save context?
3. What's missing that you'd have had to guess at during your last few tasks?
4. Are any of the rules contradicted by what the code actually does? (That's the worst kind — it makes the whole file untrustworthy.)
5. Is anything in here a secret or otherwise unsafe to have in a file that might become public?

Give me a tightened version, and tell me what you cut and why.

I'm stopping work for today. Write me a handover note I can paste at the start of tomorrow's session, and save it to docs/handover.md.

Include:
- What we were trying to achieve overall
- What's actually finished and verified working (be honest — not what we attempted)
- What's half-done, and exactly where it stopped
- Decisions we made and the reasons, especially ones that would look odd without the reasoning
- Anything currently broken that I should know about before I touch anything
- The exact next step, specific enough that I could start with it cold
- Any files that are in a messy intermediate state

Be accurate rather than optimistic. If something's a mess, say it's a mess.

I'm a non-technical founder with design experience. I'm building [describe your app in 3-4 sentences, including what users do and what data it stores].

Recommend a stack, but justify it against MY constraints specifically:
- I'll be building with AI coding tools, so I need technologies that are extremely well represented in training data
- Budget under A$80/month until I have paying users
- I'm solo, so I can't afford to run infrastructure
- I need to be able to hand this to a contract developer later without them wincing

Give me:
1. Your recommendation, layer by layer, with one sentence of justification each
2. Where my particular app has a requirement that changes the usual answer
3. What I'd be giving up versus a more sophisticated choice
4. A realistic monthly cost at 0, 100 and 1,000 users, in Australian dollars — note which services bill in USD and assume a rate of about 1 USD = A$1.55
5. The one decision here that would be most painful to reverse later, and how to stay flexible on it

Help me design the database for [describe your app]. Don't write any code yet.

Interview me about what the app needs to store, then propose a schema. For each table, show me:
- What real-world thing it represents
- Its columns, their types, and which are required
- How it connects to other tables
- Who should be allowed to read and write each row

Then:
1. Draw the relationships as a simple text diagram
2. Explain it back to me in plain English, as if describing a filing system
3. Flag the three decisions here that would be most painful to change once I have real data
4. Tell me what I've probably forgotten — the fields people always wish they'd added from the start
5. Write the row level security policies alongside the tables, and explain what each one allows

Be specific about anything involving dates, times, money or timezones — I gather those cause the most pain.

I'm a non-technical founder building [describe your app] for the Australian market. It's a [Next.js / other] app using [Supabase / other] for data.

Compare hosting options for me — Vercel, Netlify, Cloudflare, Render, Railway, Fly.io — against my actual constraints:

- I will be charging users within a few months, so non-commercial free tiers are a trap
- My users are almost all in Australia, so latency to Sydney matters
- Some customers may ask where their data is physically stored
- I'm solo and non-technical, so I can't run servers
- I want predictable costs, not usage-based surprises

For each option tell me: what the free tier really allows, what I'd pay in AUD once commercial, which regions it can run in, how hard it would be to move away later, and how well it handles my specific framework.

Then recommend one, say what I'd be giving up, and tell me the one thing that would make you change your recommendation.

I'm about to commit to [stack]. Before I do, teach me enough to be dangerous.

For each part of the stack, explain in plain English:
1. What it does, and what would break if I removed it
2. Which files in my project belong to it
3. The three concepts I need to understand to not be lost
4. The most common beginner mistake, and how to spot it
5. Where the real documentation lives, and which section to actually read

Then give me a single mental model of how a request flows through the whole stack: user clicks a button → what happens, in order, until they see a result. Name the specific files in my project at each stage.

I'm a non-technical founder building an MVP with AI coding tools. Here's my idea:

[paste your description, your users, and what they need to be able to do]

My riskiest assumption is: [the thing that, if false, means this product shouldn't exist]

Break this into vertical slices, where each slice is one complete user action that works end to end and can be demonstrated.

For each slice give me:
1. A one-line description of what the user can do afterwards
2. What has to be built (roughly, in plain English)
3. An honest estimate in evenings, for someone with my level of experience
4. What "done" means — the specific things I should click to verify it
5. What could go wrong or turn out harder than it looks

Order them so that I'm never blocked, and so that the riskiest assumption gets tested as early as possible. Then tell me which slices I could cut entirely and still run a valid experiment.

I'm about to build this slice: [description]

Before any code, write me a short specification. Ask me questions first where you'd otherwise guess.

The spec should cover:
- The user's goal and what happens immediately before and after
- Every screen or state involved, including empty, loading, error and success
- The rules: what's required, what's valid, what's not allowed
- What data this creates or changes, and what else depends on it
- Who's allowed to do this and what happens if someone who isn't tries
- Numbered acceptance criteria I can check off by clicking

Keep it under one page. Save it to docs/ with a sensible filename. Don't write code — I want to read and approve this first.

I've just finished building [slice]. Before I move on, act as a QA engineer who's been asked to break it.

Look at the actual code and tell me:
1. Ten specific ways a user could break this, with the exact steps for each.
2. What happens with no data at all, and what happens with an unreasonable amount.
3. What happens with awkward input: apostrophes in names, emoji, very long text, leading spaces, pasted formatting.
4. What happens with bad timing: double-click, slow network, refresh mid-action, two tabs open.
5. Whether one user could see or change another user's data. Be specific about how you checked.
6. Which of these actually matter before I put this in front of ten beta users, and which can wait.

Don't fix anything yet. Give me the list, ordered by how likely I am to get burned.

Audit this project honestly. I've been building with AI assistance and I suspect some things look finished but aren't.

Find and list:
1. UI elements — buttons, toggles, links, menus — that aren't wired to anything
2. Functions that are defined but never called
3. Placeholder or hardcoded data pretending to be real
4. Error handling that catches problems and silently does nothing
5. "TODO" or "FIXME" comments and what they're hiding
6. Features that work in one place but not in the equivalent place elsewhere
7. Anything that would only work for my test account

For each, tell me whether it's a must-fix, a should-fix, or a fine-for-now. Be blunt — I'd rather find this out from you than from a beta user.

Something is broken and I need the actual cause, not a quick fix.

What I expected: [describe]
What actually happened: [describe precisely, including anything odd you noticed]
Terminal output: [paste everything]
Browser console: [paste everything]
What I already tried: [list, including anything you suggested that didn't work]

Please work through this properly:
1. First, tell me what you think is happening and why — before touching anything.
2. Tell me what evidence would confirm or rule out that theory, and how to gather it.
3. Only once you're confident, make the smallest change that fixes the actual cause.
4. Explain what was wrong in plain English, and why it produced this particular symptom.
5. Tell me whether this could be happening elsewhere in the app too.

Do not change more than one thing at a time. If you're guessing, say you're guessing.

We've tried several times to fix this and each attempt has made things worse. I've reverted everything back to my last working commit, and I'm starting fresh.

The original problem, described from scratch: [describe as if we've never discussed it]

Before suggesting anything:
1. List every plausible cause you can think of, including unlikely ones.
2. For each, tell me the quickest way to rule it in or out.
3. Tell me which one you'd check first and why.

Then stop and wait for me to run the checks. Don't write any code yet.

I'd rather spend ten minutes diagnosing than another hour guessing.

I'm a non-technical founder. Teach me to read errors in this stack so I need you less for the easy ones.

Take the 15 error messages I'm most likely to see in [your stack] and for each give me:
- What the message literally says, decoded word by word
- What it actually means in practice
- The two most common causes
- Where to look first
- Roughly how worried to be (harmless / annoying / serious)

Then teach me the general skill: how to find the useful line in a wall of output, how to tell my code's errors from a library's, what stack traces are and which parts to ignore, and which warnings I can safely skip forever.

You just fixed [describe the bug]. Before I commit this, I want to be sure it's a real fix and not a workaround.

Tell me honestly:
1. What was the actual root cause?
2. What did you change, file by file, and why each change was needed?
3. Did you fix the cause or prevent the symptom? Be honest if it's the latter.
4. Did you remove, disable, or hardcode anything to make this work?
5. Is there error handling here that would hide this problem if it came back?
6. Could this same bug exist anywhere else in the app? Where should I check?
7. What should I click to verify the fix, including the case that was failing?

If you're not confident this is properly fixed, tell me now rather than after I've shipped it.

I'm a non-technical founder deploying for the first time. My project is [describe: Next.js app, Supabase, etc.] and it currently runs on my machine.

Walk me through deploying to Vercel, one step at a time, waiting for me to confirm each step.

Cover:
1. Making sure the project is ready (and what would make a build fail)
2. Connecting the GitHub repo
3. Every environment variable I need to set, and where each value comes from
4. What to check immediately after the first deploy
5. Adding a custom domain, including what the DNS records mean
6. How to tell whether it actually worked, beyond "the page loads"

For each step tell me what success looks like, and the most likely thing to go wrong. Also tell me which of my environment variables are safe to expose to the browser and which absolutely aren't — and how the naming convention indicates that.

I'm about to put this in front of real users for the first time. Audit the whole project as if you were a senior engineer signing off a launch for a non-technical founder.

Check and report on:
1. Anything that would leak data between users
2. Secrets: anything committed, anything exposed to the browser that shouldn't be
3. Missing environment variables that would break in production but not locally
4. Error handling: what happens when things fail, and would the user see something sensible?
5. Empty, loading and error states on every screen
6. Mobile: anything that breaks between 360px and 768px
7. Basic legal hygiene: privacy policy, cookie consent, terms, contact details
8. Whether I'd find out if this broke at 3am

Give me a prioritised list: must fix before launch, should fix this week, can wait. Be honest about the must-fix items — I'd rather delay a day than have a bad first week.

Help me set up error tracking and analytics so I actually know what's happening on my live site. I'm non-technical and cost-sensitive.

1. Recommend tools with genuinely usable free tiers, and tell me what each answers that the others don't.
2. Walk me through installing error tracking, step by step.
3. Show me how to trigger a test error deliberately so I can confirm it's working end to end.
4. Tell me how to set up alerts so I hear about real problems but don't get spammed.
5. Tell me the five numbers I should look at each week, and what a bad value for each would mean.

Keep it minimal. I want the smallest setup that means I'm never the last to know.

Do a security review of this project. I'm a non-technical founder about to launch to real users, so explain everything in plain English and tell me how worried to be.

Check specifically:
1. Secrets: anything committed to Git now or in history, anything exposed to the browser that shouldn't be, anything with a NEXT_PUBLIC_ prefix that looks sensitive
2. Database: is row level security on for every table? Show me each policy and explain in plain English who it lets do what. Flag any table where the answer is "anyone".
3. Authorisation: for every action that changes data, is permission checked on the server, or only by hiding UI?
4. Input validation: which endpoints accept user input without validating it server-side?
5. Data exposure: could one user see another's data by changing an ID in a URL or an API call? Show me how you checked.
6. Dependencies: anything with known vulnerabilities?

For each finding give me: what's wrong, what could actually happen, how likely it is, and the fix. Order by real-world risk, not by theoretical severity. Then tell me the three things to fix before I let anyone in.

Search this entire project — including the full Git history, not just the current files — for anything that looks like a credential: API keys, passwords, tokens, connection strings, private keys.

For each one found, tell me:
1. Where it is, and whether it's in the current code or only in history
2. What service it belongs to and what someone could do with it
3. Whether the repository is public or private, and how much that changes the urgency
4. The exact steps to fix it — including that I need to revoke and regenerate at the provider, not just delete the file

Then check my .gitignore and tell me whether anything sensitive could be committed by accident in future. Finally, show me how to set up an automatic check that stops me committing a secret again.

I'm a non-technical founder trying to keep costs predictable. My stack is [list services].

Build me a cost model:
1. Monthly cost at 0 users, 100 users, 1,000 users and 10,000 users, in Australian dollars — with the assumptions you used spelled out, including the USD exchange rate and whether GST applies
2. Which service becomes expensive first, and what specifically triggers it
3. Which of these could produce a surprise bill, and what the worst realistic case is
4. Exactly where to set spending limits and alerts on each one, step by step
5. Any free tier limit I'd hit sooner than I'd expect

If my app includes AI features, work out the cost per user per month separately and compare it to what I'd need to charge. Tell me honestly whether the unit economics work.

I'm an Australian solo founder launching a web app that stores [describe what personal data you hold]. My users are mostly in Australia, with some in [the EU / UK / elsewhere]. I have no legal budget yet.

Give me the practical minimum:
1. What I'm legally required to have in place from my first user
2. What I can reasonably defer until I have revenue
3. A plain-English list of what needs to be in my privacy policy for MY specific data, covering each jurisdiction my users are actually in
4. What "be able to delete a user" actually means technically — including data in backups, logs, and third-party services
5. Which of my third-party services process personal data, and what that means for me
6. The three mistakes small startups most commonly make here

Be practical rather than alarmist, and be clear about where you're giving general information rather than legal advice.

Act as a pragmatic technical advisor doing a weekly check-in with me. Look at this project — the code, the recent commits, the state of things.

Tell me:
1. What actually changed this week, based on commit history rather than what I think I did.
2. What's half-finished and at risk of being abandoned in an unusable state.
3. Where the codebase is getting messy: duplication, inconsistency, files that are getting too big, patterns that have drifted.
4. What's accumulating that will bite me in a month if I ignore it.
5. The single most valuable hour of cleanup I could do next week.
6. One thing I'm doing well that I should keep doing.

Be honest rather than encouraging. I'd rather hear it now.

I want to actually understand what I've built rather than just owning it. Design me a 4-week self-study plan based on THIS specific project.

Each week: one concept, the specific files in my project that demonstrate it, and a small exercise where I change something myself and predict what will happen before I run it.

Start from what I know — HTML, CSS, basic layout — and build up. Prioritise concepts by how often they appear in my code, not by what a computer science course would teach first.

For each concept, tell me: what it is, why it exists (what problem it solves), what the code would look like without it, and the mistake beginners make with it.

I'm a non-technical founder who built this app with AI tools. I want to hire a developer for [a security review / a specific feature / ongoing help].

Write me a brief I can send to a freelancer. Include:
- What the app does and who it's for
- The stack and how it's deployed
- What state the code is honestly in, including anything I should flag as messy
- Exactly what I want them to do, and what's out of scope
- What I can and can't do myself, so they know how to communicate with me
- The questions they'll probably ask, with answers prepared

Then tell me what a fair price range is for this kind of work, what a good response from a contractor looks like, and three warning signs that I've found the wrong person.

I have limited time and I keep being tempted by new features. Help me decide what to work on next, based on evidence rather than enthusiasm.

Here's what I know:
- What users have actually said or done: [paste feedback, analytics, support messages]
- What's currently half-finished: [list]
- What I'm tempted to build: [list]
- My riskiest remaining assumption: [describe]

Give me:
1. What to do next, and why that specifically
2. What to finish before starting anything new
3. What to delete or abandon outright — be willing to tell me to kill something
4. Which of my tempting ideas are procrastination dressed as progress
5. What I should do this week that isn't building at all

Push back on me if I'm avoiding talking to users.

Audit this project for scaling problems — but be realistic about my stage rather than listing every best practice.

For each issue found, tell me:
1. Where it is (file and line) and what it does
2. At roughly what scale it becomes a real problem — be specific: how many rows, users, or requests
3. What the symptom would look like to me, in plain English, when it happens
4. How hard the fix is, honestly: minutes, hours, or a project
5. Whether I should fix it now, at my next milestone, or leave it

Look specifically for: missing database indexes, queries inside loops, unbounded queries with no limit or pagination, slow work happening during a request, missing rate limits, and anything that would hold too much in memory.

Rank by "most likely to hurt me first", not by severity in the abstract. I'd rather fix three real things than read about thirty theoretical ones.

My app feels slow on [describe the page or action]. I don't want to guess at the cause.

Teach me to diagnose it properly:
1. How do I measure what's actually slow, using tools I already have — the browser's network and performance tabs, and my hosting dashboard?
2. Walk me through interpreting what I find: what numbers are normal, what numbers are bad, and where the time is actually going.
3. Based on the code, what's your hypothesis for the cause?
4. What's the cheapest way to confirm or disprove that hypothesis before changing anything?
5. Only then: what's the smallest change that would fix it, and what improvement should I expect?

Afterwards, tell me how to re-measure so I know whether the fix actually worked, rather than assuming.

I want to know whether this app will survive growth, without over-engineering for scale I don't have.

My realistic expectations: [X users in 6 months, each with roughly Y records, mostly active at Z times].

Tell me:
1. Which parts of the app would struggle first under that load, and why
2. What would break at 10x that, and at 100x
3. Which of those problems are cheap to prevent now versus expensive to fix later — this is the only list I actually care about
4. Which are fine to leave entirely until they happen
5. How I could generate realistic test data and see the slowdown for myself before real users do

Be honest if the answer is "this will be completely fine and you should go and talk to customers instead".

Someone has suggested that [describe the area, or the whole app] should be rebuilt rather than improved.

Argue both sides properly:
1. The strongest honest case for rebuilding, including what specifically is wrong that can't be fixed incrementally
2. The strongest honest case for improving it in place, including what we'd lose in a rebuild
3. What a staged, incremental version of the change would look like — could we get 80% of the benefit without stopping?
4. A realistic time estimate for each path, for a non-technical founder working with AI tools
5. What the product would cost me in lost progress during a rebuild

Then give me your actual recommendation and the one fact that would change it. Bias toward incremental unless the case for rebuilding is genuinely overwhelming.

Act as a privacy analyst. Read this project and build me a data inventory — I'm a solo founder and I've never done this.

For every piece of personal information the app collects or stores, give me a table row with:
1. What it is, and which database table and column it lives in
2. Why the app collects it (based on how it's actually used in the code — and flag anything collected but never used)
3. Who can read it: which users, which roles, and whether row level security actually enforces that
4. Which third-party services receive a copy, and which country each stores it in
5. How long it's kept, and whether anything deletes it
6. Whether it would count as sensitive information under Australian, EU or UK law

Then tell me:
- What I'm collecting that I could stop collecting entirely
- Anything a user could not currently get deleted if they asked
- Anything that would be hard to explain in a privacy policy

Save it to docs/data-inventory.md.

Trace what would happen if a user asked me to delete their account and all their data.

1. Follow the deletion path through the code, if one exists, and tell me exactly what it removes.
2. List everything that would be LEFT BEHIND: other tables, rows referencing them, logs, error-tracking records, analytics, email provider records, backups, cached data, uploaded files.
3. Tell me which of those I'm legally expected to remove under Australian, EU and UK rules, and where deletion can legitimately be deferred — backups in particular.
4. Show me what a complete, honest deletion flow would look like for this app.
5. Tell me what I should say in my privacy policy about deletion timing, so that it's both accurate and achievable.

Be blunt if the honest answer is "you cannot currently delete a user properly".

A business customer has asked about how we handle their data. Based on this project's actual architecture, draft honest answers to the questions they'll ask:

- Where is our data physically stored, and in which country?
- Who at your company can access it?
- Is it encrypted in transit and at rest?
- What third parties does it pass through, and where are they?
- How do you back it up, and have you tested a restore?
- What happens to our data if we leave?
- What's your process if you have a data breach?
- Do you use our data for anything other than providing the service, including training AI models?

For each: give me the truthful answer based on the code and infrastructure as it actually is, flag where the honest answer is weak, and tell me what the cheapest fix would be. I want to improve the real answers, not learn to phrase bad ones well.

Based on this project's actual data handling, draft the content a lawyer would need to produce a privacy policy for me — an Australian business with users in Australia, and some in the EU and UK.

Cover: what's collected and why, the legal basis for each use, who it's shared with, where it's stored and transferred, how long it's kept, individual rights under Australian, EU and UK rules, how someone contacts me, and how I handle complaints.

Be explicit about anything I'd have to fix before I could truthfully make these statements — for example if I claim data is deleted within 30 days but nothing actually deletes it.

Make clear this is a starting point for a lawyer to review, not a finished policy.

I'm a non-technical founder and I've been stuck on something. Help me decide honestly whether to keep going or get help.

The problem: [describe]
How long I've been on it: [time]
What I've tried: [list]
What I understand about the cause: [be honest, including "nothing"]

Tell me:
1. Is this something I can realistically solve with you, or does it need someone with production experience? Be honest rather than encouraging.
2. If it's solvable: what's the single next diagnostic step, and what would each possible result tell me?
3. If it needs a human: what kind of help — an hour of advice, a review, or a contractor for a piece of work?
4. What should I have ready before that conversation so I don't waste their time or my money?
5. What's the risk if I keep grinding on this alone for another day?

Consider the cost of my time, not just whether it's theoretically possible.

I'm bringing in an experienced engineer to help me. Prepare everything they'll need so the first hour is productive.

Create docs/context-pack.md containing:
1. What this product does and who it's for, in a paragraph
2. The stack, and how it's deployed
3. A map of the codebase: what lives where, and which files matter most
4. How data flows through the app for the main user journey
5. The honest state of things: what's solid, what's held together with tape, what I know is wrong
6. Known issues and technical debts, with the trigger conditions
7. What I can do myself, and what I definitely can't
8. What I want from them specifically, and what's out of scope

Be honest about weaknesses rather than presenting this favourably — they'll find out anyway, and it wastes the engagement if they find out slowly.

Someone has reviewed my project and told me [paste their assessment or recommendation].

Help me evaluate it as a non-technical founder who can't judge this directly:

1. Which parts are objectively true, based on the actual code?
2. Which parts are reasonable judgement calls where a different engineer might disagree?
3. Which parts look like personal preference presented as necessity?
4. If they've recommended a rewrite or a major change: what specifically can't be fixed incrementally, and does that hold up?
5. What questions should I go back and ask them?
6. If I did nothing they suggested, what would actually happen and when?

I'm not looking to dismiss their advice — I want to understand it well enough to make my own decision.

Help me write a short escalation plan — the things that, if they happen, mean I stop working alone and call someone immediately.

Based on my specific app ([describe], storing [what data], with [payments / no payments]), give me:
1. The five situations where I should stop touching the code immediately, and why in each case continuing makes things worse
2. The warning signs that precede each one
3. Who I'd need in each case — a developer, a security specialist, a lawyer
4. What I should do in the first ten minutes of each, before help arrives
5. What I should NOT do, especially the instinctive reactions that make things worse

Keep it to one page. Save it to docs/escalation.md so it exists before I need it.

I'm a non-technical founder. Explain [term] to me:

1. What it is, in two sentences, with no analogies
2. What problem it exists to solve — what did people do before it?
3. Where it appears in MY project specifically (point at actual files)
4. What I'd notice if it were wrong or missing
5. The one thing beginners misunderstand about it

Then show me a real example from my own code and walk through it.

Go through this project and find every piece of terminology that appears in it — library names, framework concepts, domain-specific terms, anything in the code or config that a non-technical person wouldn't recognise.

Write me a glossary, saved to docs/glossary.md, with each term explained in one or two plain sentences plus where it appears in my project.

Sort it by how often I'm likely to encounter each one, most common first. Flag the five terms I genuinely need to understand versus the ones I only need to recognise.