Prompt Library

The app I tried to build in a no-code tool was:
[DESCRIBE YOUR APP, e.g., "a meal planner that builds a week of recipes",
"a quiz maker for teachers", "a workout planner"].

I was using [WHICH NO-CODE BUILDER, e.g., Lovable / Base44 / v0 / Bolt / Replit].

It hit a wall when I tried to:
[WHERE IT BROKE OR STOPPED, e.g., "add real user logins", "save people's
data permanently", "take a payment", "change how one screen worked",
"export the code and host it myself"].

What I really want to own and control is:
[THE THING THE BUILDER WOULDN'T LET YOU DO].

My app in one sentence:
[DESCRIBE YOUR APP, e.g., "you paste a job listing and AI writes a
tailored cover letter", or "you and your flatmates share a shopping list"].

The part that has to be invented fresh each time (the brain's job) is:
[WHAT THE AI GENERATES, e.g., "the cover letter text", or write "nothing,
my app just stores and organizes" if there's no AI generation].

So my app: [NEEDS a brain / DOESN'T need a brain yet].

If it needs one, the provider I'm using is:
[Gemini / OpenAI / Anthropic / other], and my key is saved in:
[WHERE YOU SAVED IT, e.g., "my password manager"].

Build me a trip planner app.

I want to type in a destination and number of days, and it uses the Google Gemini API
to plan my trip day by day.

For each day, show me a morning activity, an afternoon activity, an evening activity,
and a restaurant recommendation.

I want this to be a simple app I can open in my browser. No complicated setup,
just one file I can open directly.

Here's my Gemini API key: [PASTE YOUR KEY HERE]

Make it look clean and easy to read.

Build me a trip planner app that I can open in my browser as a single file.

I want to type in a destination and a number of days, and have it use the
Google Gemini API to plan my trip day by day. For each day, show a morning
activity, an afternoon activity, an evening activity, and a restaurant
recommendation. Make it look clean and easy to read.

Before you build anything, show me your plan first so I can review it.
And keep the code organized so it's easy to change later.

Build me a [DESCRIBE YOUR APP, e.g., "meal planner", "quiz maker", "story generator"].

I want to [WHAT YOU DO, e.g., "type in my dietary restrictions and how many days"]
and it uses the [Gemini / OpenAI / Claude] API to
[WHAT THE AI DOES, e.g., "generate a week of recipes with ingredients and instructions"].

Show me [WHAT YOU WANT TO SEE, e.g., "each day's meals with a shopping list at the bottom"].

I want this to be a simple app I can open in my browser. No complicated setup.

Before you build anything, show me your plan first so I can review it.

Here's my API key: [YOUR KEY]   (or: use a placeholder, I'll add the key properly later)

Make it look clean and easy to read.

I want to start tracking changes to my trip planner app with Git so I can
undo mistakes and save my progress. Set it up for me, create a private
repository on GitHub, make sure it ignores files that shouldn't be tracked
(like settings files and downloaded packages), commit what I have, and push
everything up to GitHub.

Explain what each step does like I've never used Git before.

I want to start tracking changes to [YOUR APP NAME] with Git so I can
undo mistakes and save my progress. Set it up for me, create a private
repository on GitHub, make sure it ignores files that shouldn't be tracked
(like [THINGS TO IGNORE, e.g., "settings files, downloaded packages, and
any file with passwords or keys in it"]), commit what I have, and push it
all to GitHub.

Explain what each step does like I've never used Git before.

Explain what you just changed and why, in plain language.

Show me what's changed since my last save, in plain language.

Open my running app in the browser, click through [THE FEATURE YOU CARE
ABOUT], and tell me what you see, including anything that looks broken.

My API key is hardcoded in the trip planner and I pushed it to GitHub
(even though it's a private repo, I don't want secrets in my code).
Fix this, move all secret keys out of the code and into a separate
config file that doesn't get uploaded to GitHub.

Show me how to set it up so other people can see what keys they need
without seeing my actual keys.

Also, tell me how to undo the damage, is my old key still visible in the
Git history even after I remove it from the code?

My [SECRET TYPE, e.g., "API key", "database password"] is hardcoded
in [YOUR APP NAME] and I need to fix this. Move all secrets out of the
code and into a separate .env file that doesn't get uploaded to GitHub.

Create a .env.example file so other people know what keys they need
without seeing my actual values.

Make sure .env is in the .gitignore file.

[If already pushed to GitHub: "I already pushed the secrets to GitHub.
Tell me how to clean this up and what damage might already be done."]

Redesign my trip planner to look professional and modern. Use Tailwind CSS.

Make sure it's accessible for people with disabilities, good contrast,
works with keyboard only, works with screen readers. Follow WCAG AA
standards.

Add a dark mode that follows the user's system setting.

I want it to feel like a clean, modern travel app with blue accents, think
Airbnb meets Google Flights. Calm, trustworthy, easy to read.

Keep all the existing functionality exactly the same. Just make it look
like a real product instead of a homework assignment.

Redesign [YOUR APP NAME] to look professional and modern. Use Tailwind CSS.

Make sure it's accessible for people with disabilities, good contrast,
works with keyboard only, works with screen readers. Follow WCAG AA
standards.

Add a dark mode that follows the user's system setting.

I want it to feel like [STYLE DESCRIPTION, e.g., "a sleek productivity
tool with a dark theme and green accents" or "a friendly, playful app
with rounded shapes and warm colors"].

Keep all the existing functionality exactly the same. Just make it look
like a real product.

Right now my trip planner is all in one place and the API key is visible in
the browser. Split it into two parts, one that the user sees and interacts
with, and one that runs on a server where the secrets and AI logic are hidden.

The user-facing part should never have access to API keys. When the user clicks
"generate," the frontend should send a request to my server, and the server
should call the AI and send back the result.

Use Next.js to split my app into pages (what the user sees) and API routes
(where secrets and logic live). Put the page in app/page.tsx and the API
route in app/api/.

Move the API key into the .env file we set up in lesson 4.

Keep it simple. I want to understand what's happening.

Right now my [APP NAME] is all in one place and the API key is visible in
the browser. Split it into two parts, one that the user sees and interacts
with, and one that runs on a server where the secrets and AI logic are hidden.

The user-facing part should never have access to API keys. When the user
[WHAT THE USER DOES, e.g., "submits a recipe request", "asks for quiz questions"],
the frontend should send a request to my server, and the server should call
the AI and send back the result.

Use Next.js with API routes to split my app into pages (what the user sees)
and API routes (where secrets and logic live).

Move the API key into the .env file.

Keep it simple. I want to understand what's happening.

Give me a tour of my backend. Show me every API route in my project, and for
each one explain in plain language what it does, what secrets it touches, and
what rules it enforces.

Then answer this: if I ever wanted to move this backend out of Next.js into a
separate service written in Go or Python, what would have to change, and what
would stay exactly the same?

Explain it like I've never seen backend code before. I want to understand my
own kitchen.

My [APP NAME]'s backend currently runs as [Next.js API routes / WHATEVER YOU
HAVE]. The main jobs it does are [WHAT THE BACKEND DOES, e.g., "calling the AI,
saving user data, and checking who's logged in"].

Given that, walk me through which backend would fit best: staying on Next.js
API routes, a dedicated Node.js service, Python, or Go. Explain the tradeoffs
in plain language, and tell me what would stay the same no matter which I pick.

I'm not switching today. I just want to understand my options like an architect.

My trip planner page is getting big. Break it into separate components,
a search form, trip results display, and individual day cards. Each piece
should manage itself.

Keep all the existing styling and make everything work exactly the same
as before. I just want the page organized into reusable building blocks.

My [APP NAME] page is getting big. Break it into separate components,
[LIST YOUR PIECES, e.g., "an input form, a results area, and individual
result cards"]. Each piece should manage itself.

Keep all the existing styling and make everything work exactly the same
as before. I just want the page organized into reusable building blocks.

When something goes wrong in my trip planner, the user just sees a blank screen
or a confusing error. Fix this everywhere, frontend and backend.

For the user:
- If the AI takes more than 15 seconds, show a message that says the request is
  taking longer than usual and they can try again.
- If anything fails, show a friendly message explaining what happened in plain
  language. Never show the user ugly technical errors or stack traces.
- While waiting for a response, show a loading indicator so they know something
  is happening.

For me (the developer):
- On the server side, log every error with enough detail that I can figure out
  what went wrong later. Include what the user was trying to do, what went wrong,
  and when it happened.
- Log to the console for now, with timestamps.
- If the AI API returns an error, log the full error but only show the user
  a simple "something went wrong" message.

Also handle these specific cases:
- The AI service is completely down
- The user's internet disconnects
- The user sends an empty destination
- The server gets a request it doesn't understand

When something goes wrong in my [APP NAME], the user just sees a blank screen
or a confusing error. Fix this everywhere, frontend and backend.

For the user:
- If [THE EXTERNAL SERVICE, e.g., "the AI", "the recipe API"] takes more
  than 15 seconds, show a message that says it's taking longer than usual.
- If anything fails, show a friendly message in plain language.
- While waiting, show a loading indicator.

For me (the developer):
- On the server side, log every error with enough detail that I can figure
  out what went wrong later.
- Log to the console with timestamps.
- If [THE EXTERNAL SERVICE] returns an error, log the full error but only
  show the user a simple "something went wrong" message.

Also handle these cases:
- [THE EXTERNAL SERVICE] is completely down
- The user's internet disconnects
- The user submits [EMPTY OR INVALID INPUT, e.g., "no ingredients", "a blank topic"]
- The server gets a request it doesn't understand

I want to put my trip planner on the internet so anyone can use it with a link.
Set it up for Vercel.

Here's what I need:
- Make sure it has separate settings for when I'm developing on my computer
  versus when it's live on the internet. My local API key and my production
  API key should be different settings.
- Add a simple health check, a way to visit a URL and see if the app is
  running (like visiting /api/health and getting back "OK").
- Create any configuration files the hosting platform needs.
- Update the README with instructions for how to deploy this.
- Make sure environment variables (like the API key) are set through the
  hosting platform, not in the code.

I already have this project on GitHub. I want it to auto-deploy
whenever I push changes.

I want to put my [APP NAME] on the internet so anyone can use it with a link.
Set it up for [Vercel / Render / Cloudflare Pages].

Here's what I need:
- Separate settings for when I'm developing on my computer versus when it's
  live on the internet.
- A simple health check at /api/health so I can verify the app is running.
- Any configuration files the hosting platform needs.
- Update the README with deploy instructions.
- Environment variables set through the hosting platform, not in the code.

I already have this on GitHub. I want it to auto-deploy when I push changes.

My trip planner times out on Vercel when generating long trips. The browser
gives up waiting because nothing comes back for too long.

Fix it by streaming the AI response so the user sees results appearing in
real time instead of waiting for the entire response. The itinerary should
appear word by word as the AI generates it.

Also, long trips can take up to a minute to generate, so make sure the
function is allowed to run that long, set its maximum duration to the free
tier's limit of 60 seconds so it doesn't get cut off partway through. Add a
short note in the code explaining this limit.

My [APP NAME] times out when [LONG OPERATION, e.g., "generating a long
report", "analyzing a large document", "creating a detailed plan"].

Fix it by streaming the response so users see progress in real time instead
of waiting for the entire result.

Add user accounts to my trip planner using Clerk. People should be able
to sign up with email and password, log in, and log out.

Once logged in, users should only see their own trips. If someone isn't
logged in, they shouldn't be able to use the app at all, redirect them
to a sign-in page.

Use the Clerk credentials from my .env file. Install the @clerk/nextjs package.

Now I need different types of users in my trip planner. Add a role system:

- Regular users can only see and manage their own trips
- Admins can see all users, view how many trips each person has generated,
  and ban users who are abusing the system
- Add an admin dashboard at /admin that only admins can access
- If a regular user tries to go to /admin, redirect them to the main app
- If a banned user tries to log in, show them a message saying their account
  has been suspended

Store the user's role in Clerk's user metadata. Make my account an admin.
My email is [YOUR EMAIL].

Add user accounts to [APP NAME] using Clerk. Install @clerk/nextjs.
People should be able to sign up, log in, and only see their own [RESOURCES,
e.g., "recipes", "flashcards", "stories", "cover letters"].

If someone isn't logged in, they shouldn't be able to use the app at all.

Now I need different types of users. Regular users see their own stuff.
Admins can see everything, view usage stats, and ban abusive users.
Add an admin dashboard only admins can access. Store roles in [Clerk user
metadata / Supabase user table / Firebase custom claims].

Add a database to my trip planner so data is saved permanently. Use Neon
(Postgres), I've already created the database and put my connection string
in the .env file as DATABASE_URL.

I need to store users, trips, days, and activities. The relationships are:
- A user has many trips
- A trip has many days
- A day has many activities

Set up the database schema, create the tables, and update all the existing code
to read from and write to the database instead of whatever it's using now.

Use an ORM (Prisma or Drizzle) to interact with the database.

Don't change my existing database setup, but show me what the data model
would look like if I used MongoDB instead of Postgres for the trip planner.

Show me how a trip would be stored as a nested document vs how it's stored
across multiple SQL tables. Explain the tradeoffs.

I'm building [DESCRIBE YOUR APP] and need to store [DESCRIBE YOUR DATA].
Should I use SQL or NoSQL? Explain like I've never used either.

Give me a specific recommendation with reasons, not just "it depends."

I'm building a recipe app and need to store users, recipes, ingredients,
and meal plans. Recipes can have very different structures, some have
step-by-step instructions, some are just a paragraph, some have videos.
Should I use SQL or NoSQL? Explain like I've never used either.

Give me a specific recommendation with reasons, not just "it depends."

Add a database to [APP NAME] so data is saved permanently. Use Neon
(Postgres), my connection string is in .env as DATABASE_URL. I need to store
[YOUR DATA, e.g., "users, recipes, ingredients,
and meal plans"]. The relationships are:
- [RELATIONSHIP 1, e.g., "A user has many recipes"]
- [RELATIONSHIP 2, e.g., "A recipe has many ingredients"]
- [RELATIONSHIP 3, e.g., "A meal plan has many recipes"]

Set up the database schema, create the tables, and update all existing code
to read from and write to the database.

Don't change my existing database setup, but show me what the data model
would look like if I used MongoDB instead. Show me the tradeoffs.

I'm building [APP] and need to store [DATA]. Should I use SQL or NoSQL?
Explain like I've never used either. Give me a specific recommendation
with reasons, not just "it depends."

Users want to upload photos to their trips in my trip planner. Set up file
storage using Vercel Blob.

Here's what I need:
- Users can upload images (JPEG, PNG) to any of their trips
- Files should be saved to Vercel Blob, not the server's disk
- Save the file URL in the database linked to the trip
- Limit file size to 5MB per image
- Only the user who uploaded a photo should be able to see it
- Show uploaded photos as a gallery on each trip page

Use the Vercel Blob credentials already in my environment. Install the
@vercel/blob package.

Users want to upload [FILE TYPE, e.g., "recipe photos", "PDF study notes",
"profile pictures", "audio recordings"] in [APP NAME].

Set up file storage using [Vercel Blob / Cloudflare R2 / Amazon S3].
Save files in cloud storage, keep links in the database.
Limit file size to [SIZE, e.g., "5MB", "10MB", "25MB"].
Only the uploader should be able to see their files.

My trip planner app is live but it doesn't show up on Google and when I
share the link on social media it just shows a plain URL with no preview.
Add some SEO stuff so it shows up in search results.

My trip planner is live but invisible. Fix discoverability and social
sharing properly. Here's what I need:

1. Meta tags on EVERY page, not just the homepage. Each page should have
   its own unique title and description. The trip detail page for "7-Day
   Japan Itinerary" should have that as the title, not just "AI Trip
   Planner" on every page.

2. Open Graph tags for social sharing, og:title, og:description,
   og:image, og:url. These are what Twitter, Slack, iMessage, and
   WhatsApp read to build link previews. Use a default preview image for
   the homepage and the trip's cover photo (if it has one) for trip pages.
   Also add Twitter Card tags (twitter:card, twitter:title, etc).

3. A sitemap.xml file that lists all public pages on the site. It should
   update automatically when new public trips are created.

4. Structured data using JSON-LD on trip pages. Tell Google this is a
   travel itinerary, include the destination, number of days, and
   description. Use the TravelAction or TouristTrip schema from
   schema.org.

5. Server-side rendering for the critical pages, at minimum the homepage
   and any publicly shared trip pages. When a search engine or social
   media bot visits the URL, it should get a fully rendered HTML page with
   all the meta tags and content already there. It should NOT get an empty
   page that requires JavaScript to load.

6. A robots.txt file that tells crawlers they're allowed to index the
   site and where to find the sitemap.

My [APP NAME] is live but invisible to search engines and social media.
Fix discoverability and sharing:

1. Unique meta tags on every page. The [DETAIL PAGE, e.g., "recipe page",
   "listing page", "article page"] for "[EXAMPLE CONTENT]" should have
   that as the title, not a generic app name on every page.

2. Open Graph tags for social sharing, og:title, og:description, og:image,
   og:url, so links look good when shared on Twitter, Slack, and in
   messages. Use [DEFAULT IMAGE DESCRIPTION] as a fallback and the
   [CONTENT-SPECIFIC IMAGE, e.g., "recipe photo", "listing cover"] when
   available. Include Twitter Card tags too.

3. A sitemap.xml that lists all public pages and updates automatically
   when new [CONTENT TYPE, e.g., "recipes", "listings", "articles"]
   are created.

4. Structured data using JSON-LD on [CONTENT] pages. Use the
   [SCHEMA TYPE, e.g., "Recipe", "Product", "Article"] schema from
   schema.org. Include [KEY FIELDS, e.g., "cooking time and rating",
   "price and availability", "author and publish date"].

5. Server-side rendering for the homepage and all public [CONTENT] pages
   so crawlers and social media bots see fully rendered HTML.

6. A robots.txt file pointing crawlers to the sitemap.

Make my trip planner look good on phones too. Scale everything down
so it fits on a small screen.

My trip planner looks great on desktop but it's broken on phones. Redesign
it mobile-first using Tailwind responsive breakpoints.

On phones (default):
- Stack everything vertically, no side-by-side layouts
- Make the destination input and Generate button full-width
- Itinerary day cards should stack in a single column
- All buttons and tappable elements must be at least 44px tall
  (touch-friendly)
- Text should be readable without zooming, minimum 16px base font
- No horizontal scrolling ever
- Add comfortable spacing between elements so nothing feels cramped

On tablets and up (md breakpoint):
- Itinerary cards can go two per row
- Add more padding on the sides since there's room

On desktop (lg breakpoint):
- Itinerary cards three per row
- Navigation can spread out horizontally
- Use the extra space for wider margins and more breathing room

Also:
- Make sure the header and navigation work on all sizes, collapse to
  a hamburger menu on mobile if needed
- Test that the dark mode still works properly at all screen sizes
- Keep all the accessibility I already added intact, keyboard navigation,
  screen reader labels, contrast ratios

My [APP NAME] looks great on desktop but it's broken on phones. Redesign
it mobile-first using Tailwind responsive breakpoints.

On phones (default):
- Stack everything vertically, no side-by-side layouts
- Make [MAIN INPUT AND ACTION BUTTON] full-width
- [CONTENT CARDS OR LIST ITEMS] should stack in a single column
- All buttons and tappable elements must be at least 44px tall
- Text should be readable without zooming, minimum 16px base font
- No horizontal scrolling ever

On tablets and up (md breakpoint):
- [CONTENT CARDS] can go two per row
- Add more side padding

On desktop (lg breakpoint):
- [CONTENT CARDS] three per row
- Use extra space for wider margins and breathing room

Also:
- Make the header/navigation collapse for mobile if needed
- Keep dark mode and accessibility intact

Translate my trip planner app into French. Go through all the pages and
change the English text to French. The buttons, the labels, the error
messages, everything. Make it all French.

My trip planner app is only in English. I want to support multiple languages
so users from other countries can use it. Set up internationalization:

1. Extract all user-facing text into translation files, one JSON file per
   language. Start with English (en) and French (fr). Every button label,
   page title, error message, placeholder text, and status badge should
   come from these files, not be hardcoded.

2. Add a language picker in the header, a small dropdown that lets the
   user switch languages. Save their choice so it persists across sessions.
   Default to the browser's language preference using the Accept-Language
   header.

3. Format all dates using the Intl.DateTimeFormat API based on the user's
   locale. French users should see 25/12/2024, American users 12/25/2024,
   Japanese users 2024/12/25.

4. Format all currency using Intl.NumberFormat with the correct currency
   symbol and decimal style for each locale.

5. When generating an AI itinerary, include the user's language preference
   in the AI prompt so the itinerary is generated in their language.
   Something like: "Generate this itinerary in French."

6. Structure the translation files so adding a new language is just adding
   a new JSON file, no code changes needed.

7. Add dir="auto" to the HTML element so the app is ready for
   right-to-left languages in the future, even though we're not adding
   any yet.

My [APP NAME] is only in English. I want to support multiple languages.
Set up internationalization:

1. Extract all user-facing text into translation files, one JSON file
   per language. Start with English (en) and [SECOND LANGUAGE CODE]
   ([LANGUAGE NAME]). Every [LIST UI ELEMENTS, e.g., "button label,
   page title, error message, placeholder, tooltip"] should come from
   these files, not be hardcoded.

2. Add a language picker in the [LOCATION, e.g., "header", "settings
   page", "footer"] that lets users switch languages. Save their choice.
   Default to the browser's language preference.

3. Format all dates using Intl.DateTimeFormat based on the user's locale.

4. Format all numbers and currency using Intl.NumberFormat with the
   correct symbols and decimal styles for each locale.

5. [IF YOUR APP GENERATES AI CONTENT]: Include the user's language
   preference in AI prompts so generated content comes back in their
   language.

6. Structure translation files so adding a new language means adding
   one new file, no code changes.

7. Add dir="auto" to the HTML element for future right-to-left support.

My trip planner is slow for users in other countries. Make it faster
for everyone. Speed up the whole app.

My trip planner loads in 300ms from the US but 3000ms from Tokyo and
Sao Paulo. I'm on Vercel. Help me make it fast everywhere.

Specific things to check and fix:

1. CACHING, make sure Vercel is caching my static files (CSS, JS,
   images, fonts) at the edge so they're served from nearby servers, not
   my origin. Set proper Cache-Control headers. Static files should cache
   for a long time. HTML pages can have shorter cache times.

2. API RESPONSES, for API responses that don't change often (like the
   list of supported destinations or popular trip templates), add
   cache headers so Vercel can cache those at the edge too. Don't
   cache user-specific data like someone's personal trips.

3. MINIMIZE ROUND TRIPS, check if the page makes too many separate
   requests on load. Combine what you can. Make sure fonts and critical
   CSS load as early as possible, not after JavaScript runs.

4. IMAGE OPTIMIZATION, make sure trip photos and any images are served
   in modern formats (WebP) at appropriate sizes, not full-resolution
   photos scaled down in the browser. Use Vercel's image optimization
   if available.

5. Add a simple performance banner (only visible to me in dev mode) that
   shows the page load time and how many network requests were made.

My [APP NAME] loads in [FAST TIME] from [NEARBY LOCATION] but
[SLOW TIME] from [FAR LOCATION]. I'm hosted on [HOSTING PLATFORM].
Help me make it fast everywhere.

Specific things to check and fix:

1. CACHING, make sure static files (CSS, JS, images, fonts) are cached
   at the edge with proper Cache-Control headers.

2. API RESPONSES, cache [LIST API RESPONSES THAT ARE THE SAME FOR
   EVERYONE, e.g., "product catalog, popular items, category list"]
   at the edge. Don't cache [USER-SPECIFIC DATA, e.g., "user profiles,
   personal settings, order history"].

3. MINIMIZE ROUND TRIPS, reduce the number of sequential requests
   the page makes on load.

4. IMAGE OPTIMIZATION, serve images in modern formats at appropriate
   sizes.

5. Add a performance banner in dev mode showing load time and
   request count.

Add photo processing to my trip planner. When a user uploads photos,
resize each to max 1200px, analyze each with AI to generate a caption,
and save to storage. Process all photos before showing the result.

The photo processing takes too long and times out on Vercel. Fix it so when
someone uploads photos, they immediately see confirmation. Process each photo
in the background using QStash.

Here's what I need:
- When photos are uploaded, save them and immediately return "Processing..."
- Use QStash to send a callback to /api/jobs/process-photos for each photo
- Each callback processes ONE photo (resize, AI caption, save to storage)
- QStash retries failed photos automatically
- Frontend polls for progress: "3 of 10 photos ready"
- If a photo fails after retries, show an error on that specific photo

My QStash credentials:
- QSTASH_TOKEN: [YOUR TOKEN]
(Add to .env file)

[DESCRIBE THE SLOW OPERATION] takes too long and times out. Fix it so when
someone starts [THE OPERATION], they immediately see a confirmation.
Process each [UNIT OF WORK] in the background using QStash.

Here's what I need:
- When the user starts the operation, save the items and immediately
  return "Processing..."
- Use QStash to send a callback to [YOUR API ROUTE] for each [UNIT]
- Each callback processes ONE [UNIT], [DESCRIBE PROCESSING STEPS]
- QStash retries failed items automatically
- Frontend polls for progress: "[X] of [TOTAL] [ITEMS] ready"
- If an item fails after retries, show an error on that specific item

My QStash credentials:
- QSTASH_TOKEN: [YOUR TOKEN]
(Add to .env file)

Let users upload up to 20 photos at once for their trips. For each photo,
send a QStash message to process it, resize to max 1200px, AI caption,
and save to storage. Show progress as each photo completes.

Batch photo upload overwhelms the AI service when multiple users upload
at the same time. Fix it with QStash's queue features so processing
happens at a controlled pace.

My QStash credentials:
- QSTASH_TOKEN: [YOUR TOKEN]
- QSTASH_CURRENT_SIGNING_KEY: [YOUR SIGNING KEY]
- QSTASH_NEXT_SIGNING_KEY: [YOUR NEXT SIGNING KEY]

(Add these to the .env file, don't hardcode them.)

When a user uploads multiple photos:
1. Immediately save the raw files and show thumbnails with "Processing..."
   badges on each one
2. Send each photo as a QStash message, but use QStash's rate limiting
   to control delivery, max 5 per second to the callback URL
3. Each callback processes ONE photo, resize to max 1200px, AI caption,
   save to final storage
4. As each photo finishes, update the thumbnail from "Processing..." to
   the final version with its caption
5. Show progress: "3 of 20 photos ready"
6. If a photo fails, QStash retries automatically with exponential backoff
7. After 3 retries, move failed photos to dead letter, show a red badge
   with "Failed, Retry" on that specific thumbnail
8. Verify QStash callbacks using the signing keys so random people can't
   call the processing endpoint directly
9. Other users should not experience any slowdown during this process

[DESCRIBE THE BATCH OPERATION] overwhelms [THE SERVICE/SERVER] when
[TOO MANY ITEMS] are submitted at once. Fix it with QStash's queue
features so processing happens at a controlled pace.

My QStash credentials:
- QSTASH_TOKEN: [YOUR TOKEN]
- QSTASH_CURRENT_SIGNING_KEY: [YOUR SIGNING KEY]
- QSTASH_NEXT_SIGNING_KEY: [YOUR NEXT SIGNING KEY]

(Add these to the .env file, don't hardcode them.)

When a user submits [MULTIPLE ITEMS]:
1. Immediately acknowledge receipt and show [PLACEHOLDER UI] for each item
2. Send each item as a QStash message with rate limiting, max [NUMBER]
   per second
3. Each callback processes ONE item, [DESCRIBE PROCESSING STEPS]
4. As each item finishes, update the UI with the result
5. Show progress: "[X] of [TOTAL] [ITEMS] ready"
6. QStash retries failed items automatically with exponential backoff
7. After [NUMBER] retries, move to dead letter, show error with retry option
8. Verify QStash callbacks using signing keys
9. Other users should not experience any slowdown

Users can do things at the wrong time in my trip planner app. They share
trips that are still generating, edit during generation, and get weird bugs
when background jobs finish on archived trips.

Fix this by adding a state machine to trips. Every trip has a stage in its
lifecycle:

Stages:
- draft: trip created, user is setting preferences, no itinerary yet
- generating: AI is building the itinerary, in progress
- ready: itinerary is complete, fully usable
- shared: trip has been shared via link, read-only for owner
- archived: trip is stored for memories, inactive

Allowed transitions:
- draft -> generating (user clicks Generate)
- generating -> ready (generation completes)
- generating -> draft (generation fails or user cancels)
- ready -> shared (user shares the trip)
- ready -> generating (user regenerates a day or the whole trip)
- ready -> archived (user archives the trip)
- shared -> ready (user unshares the trip)
- archived -> ready (user unarchives the trip)

Rules:
- Can only share a trip that is "ready"
- Can only edit a trip that is "draft" or "ready"
- Can't start generation on a trip that is already "generating"
- Background job completion can only move a trip from "generating" to
  "ready", not from any other state
- Can only archive a trip that is "ready"
- Can only unarchive a trip that is "archived"

When someone tries to do something not allowed in the current stage,
show a clear, friendly error message explaining why. For example:
"This trip is still generating. You can share it once it's ready."

Add the stage as a field on the trip in the database. Show the current
stage as a badge on the trip card in the UI (like "Draft", "Generating...",
"Ready", "Shared", "Archived") with appropriate colors.

Users can do things at the wrong time with [RESOURCE] in my app. They
[DESCRIBE THE PROBLEM, e.g., "publish drafts, edit published content,
delete things still being processed"].

Fix this by adding a state machine to [RESOURCE].

Stages:
- [STAGE 1]: [description]
- [STAGE 2]: [description]
- [STAGE 3]: [description]
- [STAGE 4]: [description]

Allowed transitions:
- [STAGE 1] -> [STAGE 2] ([what triggers this])
- [STAGE 2] -> [STAGE 3] ([what triggers this])
- [STAGE 3] -> [STAGE 1] ([what triggers this])
[add more as needed]

Rules:
- Can only [ACTION] a [RESOURCE] that is "[STAGE]"
- Can't [ACTION] a [RESOURCE] that is "[STAGE]"
[add more as needed]

When someone tries to do something not allowed in the current stage,
show a clear, friendly error message explaining why.

Add the stage as a field in the database. Show it as a badge in the UI
with appropriate colors.

Use the most powerful AI model for every step of my trip planner, and
just trust whatever the AI returns. Don't worry about cost or limits.

Right now my trip planner uses the most expensive AI model for everything,
and the bill is getting too high. I want to use the right-sized model for
each task.

- For the easy, high-volume jobs, sorting a request into a trip type,
  writing a one-line trip summary, and [SIMPLE TASK, e.g. "cleaning up the
  user's typed description"], use a small, cheap, fast model.
- For the one job where quality really matters, building the full
  day-by-day itinerary, keep using the most capable model.

Tell me which model you're assigning to each task and roughly what each
one costs, so I can sanity-check it against the provider's current pricing
page.

Two cost fixes for my AI calls:

1. Cap how long each AI response can be. The one-line summary should be
   short, no more than [A SENTENCE OR TWO]. The full itinerary can be
   longer, but still put a sensible upper limit on it so it can't ramble
   forever.

2. My itinerary instructions have a big fixed part that's the same on every
   request (the role, the rules, the format). Set up prompt caching so we
   reuse that fixed part instead of resending and paying for it every single
   time. Keep the part that changes per request, the user's specific
   trip, at the end.

Also, don't send the AI anything it doesn't need for the task, keep the
inputs lean.

Sometimes the AI returns the itinerary as a chatty paragraph instead of the
structure my app expects, and the page breaks. Fix this by requiring the AI
to return the itinerary in a strict, fixed structure every time.

The itinerary should always come back with: a trip title, a list of days,
and for each day a date, a short summary, and a list of activities (each
with a time, a name, and a one-line description).

If the AI ever can't produce that structure, the app should handle it
gracefully, show a friendly "couldn't generate your itinerary, try again"
message instead of crashing.

I want to make sure that when I save money by switching models or editing a
prompt, I don't accidentally make the trip planner worse. Build me a small,
lightweight quality check (an "eval").

- Create about [5-8] sample trip requests, a mix, like a beach week, a
  budget city break, a family trip, a luxury honeymoon.
- For each one, write down in plain language what a GOOD itinerary should
  include (e.g. "stays within budget," "has activities every day," "matches
  the requested vibe," "comes back in the correct structure").
- Make it so I can run all these checks at once with a single command, and
  get a simple pass/fail report.
- Remind me to run it whenever I change the itinerary prompt or swap which
  model builds the itinerary.

Keep it simple, I'm not a coder. I just want a smoke detector that warns me
if quality drops before my users notice.

My [YOUR APP] uses AI and the bill is getting too high. Help me make it
cheaper and more reliable without lowering the quality where it matters.

1. RIGHT-SIZE THE MODELS
   - For easy, high-volume jobs, [LIST THE SMALL TASKS, e.g. "tagging,
     short summaries, simple rewrites"], use a cheap, fast model.
   - For the one job where quality really matters, [THE CORE TASK, e.g.
     "writing the final document," "generating the workout plan"], use the
     most capable model.
   - Tell me which model you assigned to each task and roughly what it costs.

2. CONTROL COST
   - Cap how long AI responses can be, especially for the short tasks.
   - Reuse the fixed parts of my prompts (prompt caching) instead of
     resending them every time. Keep the per-request part at the end.
   - Don't send the AI inputs it doesn't need.
   - Remind me to set a monthly spending limit at the provider.

3. FORCE A STRICT SHAPE
   - The main output ([DESCRIBE IT, e.g. "the workout plan"]) must come
     back in this exact structure every time: [LIST THE FIELDS].
   - If the AI can't produce that shape, show a friendly error instead of
     crashing.

4. ADD A QUALITY CHECK (EVAL)
   - Create [5-8] sample inputs that cover the range of what users ask for.
   - For each, write down in plain language what a good answer looks like.
   - Let me run them all with one command and get a pass/fail report.
   - Remind me to run it whenever I change a prompt or swap a model.

I want to charge money for my trip planner app. Add [Creem / Stripe]
for payments.

Pricing:
- Free plan: 3 trips per month, max 5 days per trip, no AI photo captions
- Premium plan: $10/month, unlimited trips, up to 30 days per trip,
  AI photo captions included

Here are my credentials (add to .env, never hardcode):
- [PASTE YOUR API KEYS AND SECRETS HERE]

What I need:

1. PRICING PAGE
   - Show Free vs Premium side by side
   - "Current Plan" badge on whichever plan the user is on
   - "Upgrade" button on Premium that opens the payment checkout
   - "Manage Subscription" link for existing premium users

2. PAYMENT FLOW
   - Use [Creem Checkout / Stripe Checkout], don't build a custom
     payment form, use their hosted checkout page
   - After successful payment, redirect back to the app with a
     success message
   - After cancelled payment, redirect back with no changes

3. WEBHOOK HANDLING
   - Create a webhook endpoint that receives events from [Creem/Stripe]
   - Handle these events:
     - Payment succeeded: mark user as premium in database, record
       the subscription ID
     - Payment failed: send the user a notification that their payment
       didn't go through, give them 7 days to update their card before
       downgrading
     - Subscription cancelled: keep premium until end of billing period,
       then downgrade to free
     - Subscription renewed: update the billing period end date
   - Verify webhook signatures so nobody can fake a payment event

4. ACCESS CONTROL
   - Check the user's plan before allowing premium features
   - If a free user tries to create a 4th trip in a month, show
     "You've used all 3 free trips this month. Upgrade to Premium
     for unlimited trips."
   - If a free user tries to create a trip longer than 5 days, show
     a similar upgrade prompt
   - If a free user tries to use AI photo captions, show upgrade prompt

5. DATABASE
   - Store subscription status on the user record: plan (free/premium),
     subscription ID, current period end date, payment provider customer ID
   - Keep a log of all payment events for debugging

6. TESTING
   - Make sure this works in [Creem Test Mode / Stripe Test Mode]
   - Use test credit card numbers, not real ones

I want to charge money for [YOUR APP]. Add [Creem / Stripe] for payments.

Pricing:
- Free plan: [LIMITS, e.g., "5 documents per month, basic features"]
- Premium plan: $[PRICE]/month, [FEATURES, e.g., "unlimited documents,
  AI analysis, priority support"]

Here are my credentials (add to .env, never hardcode):
- [YOUR API KEYS]

What I need:

1. PRICING PAGE, show plans side by side with upgrade button
2. PAYMENT FLOW, use hosted checkout, redirect back after payment
3. WEBHOOK HANDLING, handle payment success, failure, cancellation,
   and renewal. Verify webhook signatures.
4. ACCESS CONTROL, check plan before allowing premium features. Show
   friendly upgrade prompts when free users hit limits.
5. DATABASE, store subscription status, subscription ID, billing period
6. TESTING, use sandbox/test mode with test credit cards

Add password reset to my trip planner. When a user clicks "Forgot
password," let them type in their email, and send them a link to
reset it.

I want my trip planner to send real email through Resend. Set up
Resend in the app.

- I've created a Resend account and added my sending domain,
  [YOUR DOMAIN, e.g. yourtripplanner.com].
- My Resend API key is in an environment variable called
  RESEND_API_KEY. Use it from there, never hardcode it, never
  commit it to git.
- Walk me through verifying my domain: tell me exactly which DNS
  records (SPF, DKIM, DMARC) Resend wants me to add and where to
  paste them, so my email is trusted and doesn't land in spam.
- Set up the sending "from" address as [SENDER, e.g.
  hello@yourtripplanner.com].
- Add a simple test command or route I can trigger to send myself
  one test email, so I can confirm delivery works before we build
  anything real.

Now use Resend to send two transactional emails. Design the
templates with React Email so they look clean.

1. WELCOME EMAIL, when a new user finishes signing up, send them
   a friendly welcome email. Greet them by name (pull their name
   and email from the user record in the database). Briefly say
   what the app does and link them to create their first trip.

2. "YOUR ITINERARY IS READY" EMAIL, when a trip finishes
   generating, email the trip's owner to tell them it's ready,
   with a direct link to view it. Look up who owns the trip and
   their email from the database.

Important: send BOTH of these from a background job using QStash,
not inline. Generating and sending email is slow, and I don't want
it blocking the signup response or holding up the trip-generation
flow. Hand the send off to the background and respond to the user
immediately.

Now add a working "forgot password" flow that actually sends the
email through Resend.

- A "Forgot password" page where the user enters their email.
- Generate a secure, single-use, time-limited reset link.
- Email that link to the user through Resend, using a clean React
  Email template.
- A "set a new password" page the link leads to.
- For security: always show the same "if that email exists, we've
  sent a reset link" message, whether or not the email is actually
  in our database, so nobody can use this form to discover which
  emails have accounts.
- The reset email is time-sensitive, so send it directly from the
  API route (not a background job) so it goes out right away, but
  keep the response to the user fast.

Remember the API key stays in the RESEND_API_KEY environment
variable.

I want [YOUR APP] to send transactional email through Resend.

Setup:
- My Resend API key is in an environment variable (RESEND_API_KEY).
  Use it from there, never hardcoded.
- Help me verify my sending domain [YOUR DOMAIN] with the SPF, DKIM,
  and DMARC DNS records so email doesn't land in spam.
- Send from [SENDER ADDRESS] and design templates with React Email.

Emails to send:
1. WELCOME, when [SIGNUP HAPPENS], greet the user by name (from the
   database) and point them to [FIRST ACTION].
2. [YOUR "IT'S READY" EMAIL], when [SLOW THING FINISHES, e.g.
   "the report is generated", "the file is processed"], email the
   user a link to it. Send this from a QStash background job so it
   doesn't block anything.
3. PASSWORD RESET, a forgot-password flow that emails a secure,
   single-use, time-limited reset link. Send this directly so it's
   fast. Always show the same message whether or not the email
   exists in our database.

I'm getting users from Europe in my trip planner app and need GDPR compliance.
Add the following:

1. Cookie consent banner, blocks all tracking and analytics until the user
   clicks "Accept." If they click "Decline," the app works normally but no
   tracking runs. The banner should be dismissible and not show again once
   they've chosen.

2. Privacy policy page, written in plain English, not legalese. Cover what
   data we collect (email, name, trip data, uploaded photos), why we collect
   it, how long we keep it, and that Paddle handles payment data as our
   Merchant of Record. Include a section about cookies and analytics.

3. "Download my data" button in account settings, when clicked, it gathers
   ALL of the user's data (profile info, all trips, all uploaded files,
   payment history references) and exports it as a ZIP file containing a
   JSON summary and their original uploaded files.

4. "Delete my account" button in account settings, when clicked, show a
   confirmation dialog, then permanently delete everything: the user account,
   all their trips, all uploaded files from storage, all associated records.
   This should be irreversible.

5. Record consent timestamps, when a user accepts or declines cookies,
   store the choice and timestamp in the database. Same for when they
   agreed to the privacy policy at signup.

Add a link to the privacy policy in the site footer and on the signup page.

I'm getting users from Europe in [YOUR APP NAME] and need GDPR compliance. Add:

1. Cookie consent banner, blocks [TRACKING TOOLS YOU USE, e.g., "Google Analytics,
   Mixpanel, any marketing pixels"] until the user accepts. Works normally if declined.

2. Privacy policy page, plain English. We collect [LIST YOUR DATA, e.g., "email,
   name, preferences, uploaded content, usage history"]. Explain why we collect it,
   how long we keep it, and who else sees it.

3. "Download my data" button, exports ALL user data as a ZIP: [LIST EVERYTHING,
   e.g., "profile, preferences, all generated content, all uploaded files, account
   history"].

4. "Delete my account" button, permanently deletes everything: [LIST EVERYTHING
   TO DELETE, e.g., "account, all content, all files, all associated records"].
   Irreversible after confirmation.

5. Record consent timestamps in the database.

Link the privacy policy in the footer and signup page.

I need to know when my trip planner app breaks before users tell me.
Set up monitoring with Sentry and BetterStack.

For Sentry (error tracking):
- Install the Sentry SDK and configure it with my DSN: [PASTE YOUR SENTRY DSN]
- Capture all unhandled errors automatically (server and client side)
- Add extra context to errors: which user was affected, what they were doing
- Track page load performance
- Add custom tracking for key business events: trip generated, payment completed,
  photo uploaded, account deleted

For BetterStack (uptime monitoring):
- Create a dedicated /health endpoint that checks: can the app reach the database?
  Can it reach external services like QStash and file storage? What's the recent
  error rate? Return a clear status.
- I'll point BetterStack at this endpoint to monitor uptime.

Also add a simple status dashboard route (/status) that I can check myself,
show database connection status, whether external services (QStash, file storage)
are reachable, the recent error rate, and when the last successful health check ran.

I need to know when [YOUR APP NAME] breaks before users tell me.
Set up monitoring with Sentry and BetterStack.

For Sentry:
- Install and configure with my DSN: [YOUR SENTRY DSN]
- Capture all unhandled errors with full context
- Track performance for [KEY PAGES, e.g., "the dashboard, the main form,
  the results page"]
- Add custom event tracking for [BUSINESS EVENTS, e.g., "recipe generated,
  quiz completed, document exported"]

For BetterStack:
- Create a /health endpoint that checks [YOUR DEPENDENCIES, e.g., "database,
  external API connections, message queue"]
- I'll configure BetterStack to monitor this endpoint

Add a /status dashboard showing [WHAT YOU WANT TO SEE, e.g., "server uptime,
memory, database status, recent error count"].

My trip planner works and doesn't crash. I'll just keep shipping
features and hope users like them.

I want to start understanding how people actually use my trip planner,
not just whether it crashes. Set up PostHog for product analytics.

Here are my PostHog credentials (put these in environment variables,
never hardcode them):
- Project API key: [PASTE YOUR POSTHOG PROJECT API KEY]
- Host URL: [PASTE YOUR POSTHOG HOST, e.g. https://us.i.posthog.com]

What I need:
- Add the PostHog SDK to my Next.js app, set up on both the frontend
  and the backend.
- Automatically track page views so I can see which pages people visit.
- Capture these key events at the moments they actually happen:
    - "signed_up", when someone creates an account
    - "trip_started", when someone begins creating a trip
    - "trip_generated", when the AI finishes building an itinerary
    - "photo_uploaded", when someone uploads an inspiration photo
    - "trip_shared", when someone shares a trip with a friend
    - "upgraded_to_premium", when someone pays for premium
- Be mindful of privacy: don't send personal data we don't need (no
  raw photo contents, no full itinerary text). Just record that the
  action happened, and respect user consent.

After this, I should be able to open my PostHog dashboard and see
real events arriving as I click around the app.

Now I want to see where people drop off in my main flow. The core
journey in my trip planner is:

  1. landed on the site
  2. started creating a trip ("trip_started")
  3. generated the itinerary ("trip_generated")
  4. shared the trip ("trip_shared")

Make sure every one of those steps is being captured as an event so
I can build a funnel from them in PostHog. Then tell me, step by step,
how to set up this funnel in the PostHog dashboard so I can see how
many people make it through each stage and exactly where the biggest
drop-off happens.

If any of these events are missing or fire at the wrong moment, fix
them so the funnel is accurate.

I built a new feature, [DESCRIBE THE FEATURE, e.g. "a redesigned
itinerary layout" or "AI-suggested activities"]. Before I give it to
everyone, I want to test it on a small group and measure whether it's
actually better.

Set this up using a PostHog feature flag:
- Create a feature flag called "[FLAG NAME, e.g. new_itinerary_layout]".
- Show the new feature only to users who have the flag turned on; show
  everyone else the current version.
- Start by rolling it out to just 10% of users.
- Track the key events (like "trip_generated" and "trip_shared") so I
  can compare the 10% who see the new version against everyone else.

Make sure I can change the rollout percentage or turn the flag off
completely from the PostHog dashboard, without you redeploying the app.

I want to understand how people actually use [YOUR APP NAME], not just
whether it crashes. Set up PostHog for product analytics.

Here are my PostHog credentials (put these in environment variables,
never hardcode them):
- Project API key: [YOUR POSTHOG PROJECT API KEY]
- Host URL: [YOUR POSTHOG HOST]

What I need:
1. EVENTS, capture these key actions at the moment they happen:
   - "signed_up", when someone creates an account
   - "[YOUR CORE ACTION]", e.g. "recipe_generated", "document_exported",
     "workout_logged", "quiz_completed"
   - "[A SECOND MEANINGFUL ACTION]"
   - "upgraded_to_premium", when someone pays
2. FUNNEL, my core flow is [LIST YOUR STEPS, e.g. "landed → started a
   document → exported it → shared it"]. Make sure each step is an event
   and tell me how to build the funnel in PostHog to see where people
   drop off.
3. FEATURE FLAG, I want to test [A NEW FEATURE] on 10% of users first
   and measure before rolling out to everyone.
4. PRIVACY, only track behavior, not personal data I don't need, and
   respect user consent.

I want to package my trip planner app so it runs as self-contained as
possible using Docker. The database and job queue should run fully locally;
auth uses Clerk's dev mode (a free dev key, but it still reaches Clerk's
servers).

Set up the following:

1. A Dockerfile for the app, install the right version of Node, copy the
   code, install dependencies, and start the server. Make it production-ready
   (small image size, non-root user, proper caching of dependency installs).

2. A docker-compose.yml that starts EVERYTHING with one command, the full
   stack with local substitutes for our external services where possible:
   - Next.js app container, our app itself
   - PostgreSQL container, replaces Neon (your production Postgres) locally (fully offline)
   - Clerk in dev mode, use CLERK_SECRET_KEY with Clerk's free development
     instance so auth works with test users, no production keys needed.
     Note: this dev instance still talks to Clerk's servers, it's not a
     fully offline local container like the database and queue.
   - QStash local mock, either use QStash's local development server or
     a simple HTTP relay container that mimics QStash by forwarding HTTP
     requests to our background job endpoints
   All wired together so they can talk to each other. Include environment
   variables that point the app at the local services instead of the
   production ones.

3. A .dockerignore file so we don't copy unnecessary files into the
   container (node_modules, .git, .env, etc.)

4. Update the README with clear instructions: "clone the repo, run
   docker compose up, open localhost:3000." Anyone should be able to run
   this with almost no setup, just a free Clerk dev key for auth, and no
   knowledge of the rest of the tech stack.

Make sure the development workflow is good, I want to be able to edit code
on my machine and see changes without rebuilding the container every time.

I want to package [YOUR APP NAME] so it runs completely self-contained
using Docker. No external services needed.

Set up:
1. Dockerfile, use [YOUR LANGUAGE/RUNTIME, e.g., "Node 20", "Python 3.12"].
   Production-ready (small image, non-root user, cached dependency installs).

2. docker-compose.yml, one command starts everything:
   - The app
   - [YOUR DATABASE, e.g., "PostgreSQL", "MySQL", "MongoDB"]
   - [LOCAL SUBSTITUTES FOR EXTERNAL SERVICES, e.g., "a local mock for
     Stripe webhooks", "a dev-mode auth provider", "a local S3-compatible
     store like MinIO"]
   All connected on a private network. Zero external dependencies.

3. .dockerignore, skip [UNNECESSARY FILES, e.g., "node_modules, .git, .env,
   test files, documentation"].

4. README instructions, anyone should be able to clone and run with just
   Docker. No signups. No API keys.

Support live code editing during development without rebuilding.

My trip planner app can't handle traffic spikes, one server isn't enough.
Set up load balancing so I can run multiple copies.

1. Add Nginx as a load balancer in my docker-compose setup. It should sit
   in front of my app and split traffic between multiple copies.

2. Configure docker-compose to run 3 copies of my app behind Nginx. Every
   copy connects to the same database, so they all share the same data.

3. Make sure the app is stateless, nothing important stored in one copy's
   memory. Login state already lives in the user's login token, and uploaded
   files already go to external storage. If anything still relies on server
   memory (like a temporary cache), move it to a shared store every copy can
   reach, such as the database or Redis.

4. Add health checks so Nginx automatically stops sending traffic to a
   copy that crashes or becomes unresponsive. When the copy recovers,
   start sending traffic to it again.

5. Make it easy to scale, I should be able to change the number of app
   copies with a single command or config change.

6. Add request logging to Nginx so I can see which copy handled each
   request and how the load is distributed.

My [YOUR APP NAME] can't handle traffic spikes, one server isn't enough.
Set up load balancing:

1. Add Nginx as a load balancer in Docker Compose, splitting traffic between
   multiple copies of my app.

2. Run [NUMBER] copies of the app, all sharing the same [DATABASE] and shared store (e.g., Redis).

3. Make the app stateless:
   - Sessions in a shared store like Redis (not server memory)
   - File storage in [EXTERNAL STORAGE, e.g., "S3", "Vercel Blob", "Cloudflare R2"] (not local disk)
   - Caching in a shared store like Redis (not in-memory objects)
   - [ANY OTHER STATE, e.g., "WebSocket connections need sticky sessions
     or a Redis adapter"]

4. Health checks, Nginx stops routing to unhealthy copies automatically.

5. Easy scaling, change copy count with one command.

I want to run my Dockerized trip planner on a real cloud server using
Oracle Cloud Infrastructure (OCI) free tier.

Walk me through the full process:

1. Creating an OCI account and launching an ARM Ampere A1 instance
   (use the always-free tier, up to 4 OCPUs and 24GB RAM on one instance)

2. SSH-ing into the instance from my terminal

3. Installing Docker and Docker Compose on the server

4. Getting my docker-compose.yml and project files onto the server
   (either git clone or scp)

5. Running docker compose up so my app is live on the server's public IP

6. Setting up a firewall rule so port 80 and 443 are open to the internet

7. Optionally pointing a domain name at the server

Explain every step like I've never touched a Linux server before.
Don't skip anything, if I need to click a button in the OCI console,
tell me which button.

I want to run my Dockerized [APP NAME] on a real cloud server using
[OCI free tier / AWS EC2 / GCP Compute Engine].

Walk me through the full process:

1. Creating an account and launching a virtual machine
   ([INSTANCE TYPE, e.g., "ARM Ampere A1 on OCI", "t2.micro on AWS",
   "e2-micro on GCP"])

2. SSH-ing into the instance

3. Installing Docker and Docker Compose

4. Getting my project files onto the server

5. Running docker compose up so my app is live

6. Opening the right ports ([YOUR PORTS, e.g., "80 and 443",
   "3000", "8080"])

7. Optionally pointing [MY DOMAIN] at the server

Explain every step like I've never touched a Linux server before.

I want to see Kubernetes work on my own machine, as a learning sandbox, not
for production. My trip planner already has a Dockerfile from the Docker lesson.

Walk me through, step by step, like I've never used Kubernetes before:

1. Installing a local single-node cluster with minikube (or k3s if that's
   simpler on my system), plus the kubectl command I'll use to talk to it

2. Building my trip planner's Docker image so the local cluster can see it

3. Writing the two simplest Kubernetes files I need: a Deployment that runs my
   app, and a Service that lets me reach it in a browser

4. Applying them with kubectl, and giving me the command to open my app

5. The commands to see my running pods, and to tear the whole thing down when
   I'm done

Explain what every file and command does in plain language. If something needs
to be installed first, tell me exactly what and how for my operating system.

I want to try Kubernetes on my own machine as a learning sandbox, not for
production. My [APP NAME] already has a Dockerfile.

Walk me through, step by step, as a total beginner:
1. Installing a local single-node cluster (minikube or k3s) and kubectl
2. Building my app's image so the cluster can see it
3. Writing the simplest Deployment and Service for [WHAT YOUR APP NEEDS, e.g.,
   "one web container on port 3000"]
4. Applying them and opening my app in a browser
5. Scaling to [NUMBER] copies, then tearing it all down

Explain every file and command in plain language for my operating system.

I need automated end-to-end tests for my trip planner so I stop accidentally
breaking things. Use Playwright to test the main user flows:

1. Sign up with email and password, then log in
2. Create a new trip, pick a destination, set number of days, generate itinerary
3. Upload a photo to an existing trip and verify it appears in the trip view
4. Share a trip via link and verify the shared link shows the trip
5. Subscribe to premium and verify premium features are accessible

Each test should run independently, don't rely on one test's data for another.

Set it up so I can run all tests with one command. Also set it up to run
automatically in GitHub Actions on every push. If any test fails, the push
should be flagged as failing.

Keep the test descriptions readable, I want to understand what each test
is checking just by reading the test names.

Look at my entire trip planner app, every route, every feature, every form.
Tell me what user flows I should be testing that I'm NOT testing yet.
Focus on things that would be embarrassing if they broke in production.
Prioritize by impact, what would affect the most users?

I need automated end-to-end tests for [APP NAME] so I stop accidentally
breaking things. Use Playwright to test the main user flows:

1. [FIRST CRITICAL FLOW, e.g., "Sign up and log in"]
2. [SECOND CRITICAL FLOW, e.g., "Create a new [THING] and see it on the dashboard"]
3. [THIRD CRITICAL FLOW, e.g., "Upload a file and verify it appears"]
4. [FOURTH CRITICAL FLOW, e.g., "Share [THING] with another user"]
5. [FIFTH CRITICAL FLOW, e.g., "Complete a purchase and verify access"]

Each test should run independently. Set it up to run in GitHub Actions on
every push. If any test fails, flag the push as failing.

Keep test names readable.

I'm tired of manually testing and deploying my trip planner. Set up a full
CI/CD pipeline with GitHub Actions.

When I push to any branch:
1. Check for code errors (linting)
2. Run my Playwright end-to-end tests
3. If everything passes, build a Docker container
4. Push the container to GitHub Container Registry (ghcr.io)
5. Tag it with the git commit hash so I can track which code is in which image

When I push to the main branch and everything passes:
6. Automatically deploy to my staging server
7. After staging deploy, require manual approval to deploy to production

Set up the GitHub Actions workflow file. Explain each step so I understand
what the pipeline is doing and why.

Also set up a simple status badge I can see in my repository README that
shows if the pipeline is passing or failing.

Set up a full CI/CD pipeline with GitHub Actions for [APP NAME].

When I push to any branch:
1. Check for code errors
2. Run my [TEST TYPE, e.g., "Playwright E2E tests", "API tests"] tests
3. Build a Docker container
4. Push to GitHub Container Registry

When I push to main:
5. Auto-deploy to staging
6. Manual approval to deploy to production

Explain each step so I understand what it's doing.

I almost ran a test migration on my production database. Set up my trip
planner with three completely separate environments so this can never happen.

1. Development (my laptop)
   - Local database with fake/seed data
   - Local file storage
   - Test API keys that don't charge real money
   - A clear indicator in the app that shows "DEVELOPMENT" so I always
     know where I am

2. Staging (test server)
   - Its own separate database (not shared with prod)
   - Its own file storage bucket
   - Test payment keys (Stripe test mode or equivalent)
   - Deployed automatically from the CI/CD pipeline

3. Production (live server)
   - Its own database, completely isolated
   - Its own file storage bucket
   - Real payment keys
   - Only deployed through CI/CD with manual approval

For each environment, create a separate .env file (.env.development,
.env.staging, .env.production). Make it so the app reads the right one
based on which environment it's running in.

Add a safety check, if the app detects it's running in development mode
but is connected to the production database, it should refuse to start and
show a clear error.

Explain the whole setup so I understand how the separation works.

Set up [APP NAME] with three completely separate environments so I can
never accidentally touch production data from my laptop.

1. Development (my laptop)
   - Local database with fake data
   - Local [STORAGE TYPE, e.g., "file storage", "uploads folder"]
   - Test API keys for [SERVICES YOU USE, e.g., "payment processing",
     "email sending", "AI API"]
   - Visual indicator showing "DEVELOPMENT"

2. Staging (test server)
   - Its own separate database
   - Its own [STORAGE]
   - Test [SERVICE] keys

3. Production (live server)
   - Completely isolated
   - Real keys
   - Only deployed through CI/CD with approval

Add a safety check, if the app detects a mismatch between the environment
name and the database it's connecting to, refuse to start.

Look at the full architecture of my trip planner, every service, database,
queue, storage bucket, API connection, and infrastructure piece.

Write me an architecture review that covers:

1. ARCHITECTURE MAP
   Draw a text diagram showing every component and how they connect.
   Include the frontend, backend, database, cache, queue, file storage,
   payment service, monitoring, CDN, and anything else in the system.

2. WHAT I'D DO DIFFERENTLY
   If I were starting this project from scratch today, knowing what I know
   now, what architectural decisions would I change? What would I keep?

3. WEAKEST LINK
   What's the single most fragile part of this system? The thing most
   likely to cause a problem next? Why?

4. SCALING LIMITS
   If I suddenly got 10x the users tomorrow, what breaks first? What's
   the first bottleneck? What would I need to upgrade or redesign?

5. TECHNICAL DEBT
   What shortcuts did we take that are fine for now but will cost me
   later? For each one, should I fix it now, fix it when it hurts, or
   leave it alone?

6. WHAT'S ACTUALLY GOOD
   What parts of this architecture are solid? What would a senior
   engineer look at and say "yeah, that's done right"?

Write this as a clear reference document I can come back to. Be honest.
Don't sugarcoat the weak spots, and don't undersell the strong ones.

Look at the full architecture of [APP NAME], every service, database,
connection, and infrastructure piece.

Write an architecture review covering:

1. ARCHITECTURE MAP, diagram of every component and connection
2. WHAT I'D DO DIFFERENTLY, if starting over today
3. WEAKEST LINK, the most fragile part of the system
4. SCALING LIMITS, what breaks first at [10x / 100x / 1000x] users
5. TECHNICAL DEBT, shortcuts to fix now, fix later, or leave alone
6. WHAT'S ACTUALLY GOOD, what's solid and well-built

Write it as a clear reference document. Be honest.