Scan this code for anything that should not be in a file I might share:
API keys, tokens, passwords, connection strings, private URLs.
<paste>
For each one found:
- Move it to an environment variable and show me the changed line.
- Give me the .env.example entry with a placeholder value.
- Tell me the .gitignore lines I need.
Then tell me what to do about any key that has already been committed.
The answer to the last question is always "rotate it". A secret that has been in a file you shared is a secret someone else has.
Here is a page from my site: <paste the HTML>
Fix the fundamentals:
- One h1 that matches what the page is actually about.
- A title under 60 characters and a description under 155 that would
make someone click. Written for people, not for a crawler.
- Canonical URL, Open Graph and Twitter card tags.
- Descriptive link text — never "click here" or "read more".
- Any structured data that genuinely applies. Don't invent schema.
Then tell me the one thing about this page that would rank it better.
Almost all of the value is in the title, the description and having something worth reading. The rest is housekeeping.
This feels slow: <describe what, and where — first load? a click?>
Don't optimise anything yet. First:
1. Tell me how to measure it, with the specific tool and what number
I'm looking for.
2. List the likely causes for this kind of slowness, ordered by how
often they're the real one.
3. Tell me which single measurement would tell us which it is.
Once I report back with numbers, then we fix the biggest one.
Optimising without measuring is how people spend a day shaving 4ms off a function while a 2MB image loads above it.
I'm about to share this with real people. Here is the code: <paste>
Go through it as if you were the first stranger to use it. Report:
- Anything that breaks on a phone.
- Anything that breaks with slow or no network.
- Anything that breaks if a user types something unexpected, or nothing.
- Anything that leaks a key, a path, or an internal error message.
- Anything that would lose someone's work — an unsaved form, a refresh.
Rank the findings by how embarrassing they'd be, worst first.
"How embarrassing, worst first" gets you a better ordering than "by severity". Models understand social consequence surprisingly well.
The handful of holes that account for most break-ins.
security-pass.txt
Review this for security holes: <paste>
Check specifically for:
- User input reaching a database query or a shell command unescaped.
- User input reaching the page unescaped.
- Any route that changes data without checking who is asking.
- Any route that returns someone else's data if I change an ID in the URL.
- Secrets in the source, and errors that leak internals to the user.
For each finding: the line, what an attacker does with it, the fix.
Rank by how easy it would be to exploit with no special access.
Changing an ID in a URL and getting someone else's record is the most common real-world flaw in vibe-coded apps. Check that one first, every time.
You are running all of it, whether you read it or not.
dependency-audit.txt
Here is my dependency list: <paste package.json / requirements.txt>
For each one, tell me:
- What it does, in one line, and which of my features needs it.
- Whether it's actively maintained.
- Whether I could drop it for a dozen lines of my own code.
Then flag: anything I appear not to use at all, anything with a known
advisory, and any two packages doing the same job.
Every dependency is code you ship without reading, updated by someone you have never met. Fewer is genuinely safer.
Add logging to this: <paste>
I want to be able to answer, from logs alone: what happened, to whom,
when, and what the app did next.
- Log at boundaries: requests in, calls out, jobs started and finished.
- Include an ID that lets me follow one request across every line.
- Never log passwords, tokens, card numbers, or full personal records.
- Errors get the stack trace; normal operation does not.
Tell me what you deliberately did not log, and why.
Logs you cannot correlate are just noise with timestamps. One request ID threaded through everything is worth more than ten extra log lines.
Three events you'll actually look at beats thirty you won't.
analytics-events.txt
My tool does <this>. Success for me looks like <what>.
Propose the smallest set of events that would tell me whether it's
working. For each: the name, when it fires, and the specific question
it answers.
Then tell me which of them I could get from server logs I already have,
so I don't add a tracking script for something I can already see.
Nothing that identifies a person unless I say I need it.
If you cannot say what decision an event would change, don't collect it. Unused analytics is a privacy liability with no upside.
Put this new feature behind a switch: <describe the feature>
- Off by default. On for me, so I can test it in the real thing.
- One place in the code that decides — not a check scattered
everywhere.
- Both paths must work. Show me how I'd verify that.
- Tell me how I'd remove the flag afterwards, and put a note in the
code saying when it should go.
Flags left in forever become a maze of conditions nobody dares delete. Decide the removal date when you add it.
I'm about to deploy this change: <describe>
Before I do, write the rollback plan:
- The exact steps to get back to the current version.
- How long that takes, and whether anyone loses data doing it.
- Anything in this change that CANNOT be rolled back — schema changes,
emails sent, third-party state — and how to make those reversible
or safe to leave in place.
- The first three things I should check after deploying.
Code rolls back easily. Migrations, sent emails and charged cards do not. Know which of those you're about to do.
My project: <stack, and roughly what it does>
I want it live at: <a domain / any URL will do>
Recommend one host that fits, and say what it costs. Then give me the
deploy steps as a numbered list I can follow without prior knowledge.
Include the things that always bite:
- Environment variables in the host, not in the repo.
- Whatever needs to differ between local and production.
- HTTPS.
- How I check it actually worked, beyond the page loading.
"The page loads" is not a deployment test. Submit a form, trigger an error, log in — the parts that touch config are the parts that break in production.
Here is my project: <paste the main files or describe the structure>
Write the README. Keep it short and put it in this order:
1. What this is and who it's for. Two sentences.
2. How to run it locally — every command, in order, from a clean clone.
3. The environment variables it needs and what each is for.
4. How to deploy it.
5. The three things a newcomer would get wrong.
No badges, no table of contents, no "contributions welcome" boilerplate.
Point 5 is the only part nobody else can write. It is also the part you will need most when you come back to this.
Future you is reading this in a bisect at midnight.
commit-message.txt
Here is my diff: <paste>
Write the commit message.
- A subject line under 72 characters, imperative mood, saying what
changes and not what file changed.
- A body only if the WHY isn't obvious from the diff. Explain the
reason and what you considered instead.
- If this diff is really two unrelated changes, say so and tell me
where to split it.
"Update code" is a message that costs someone twenty minutes later. If the diff does two things, that is the finding, not the message.
Diff: <paste>
Write a description aimed at someone who has not been in my head:
- What this changes, and why now.
- How I tested it, and what I did not test.
- The riskiest part of this change and what to look at closely.
- Anything I deliberately left for later.
Keep it under 200 words. Do not list every file — the diff does that.
Naming the riskiest part yourself is what gets a review that finds real problems instead of comments about spacing.
Here is what I'm building: <describe, including anything that calls a
paid API or model>
Estimate the monthly cost at 10 users, 1,000 users and 100,000 users.
Show the arithmetic so I can check it and change the assumptions.
Then:
- Which line grows fastest, and what makes it grow?
- What's the cheapest change that halves the biggest line?
- Where could a bug or a bored stranger run the bill up, and what
limit stops that?
The last question is the one that matters. Unmetered API calls behind a public form is a way to fund someone else's project with your card.
My app is live at <url>. Stack: <stack>. I currently have no
monitoring.
Set up the minimum that's genuinely worth having:
- An uptime check, and what URL it should hit. Not the homepage —
an endpoint that actually exercises the database.
- Error reporting that captures exceptions with stack traces and
sends them somewhere I'll see.
- An alert channel that reaches me, and a rule so one outage isn't
fifty messages.
Recommend specific services with free tiers, and tell me what each
step actually costs me in time.
Then: what should the health endpoint check, and what should it
deliberately not check?
A health check that only returns "OK" tells you the web server is up. Have it touch the database, or it will happily report health while every page 500s.
My data lives in <database / files / both>, hosted on <host>.
Set up backups:
- What's backed up, how often, and where it's stored — somewhere
separate from the thing being backed up.
- How long they're kept, and how much that costs.
- Whether my host already does this, and what its restore process
actually involves. Many "automatic backups" are harder to restore
than people assume.
Then the important part: give me the exact steps to restore into a
fresh environment, so I can run them now as a test.
Also: what ISN'T covered — uploaded files? environment config? Those
are usually the gap.
Do the restore. Today, into a scratch environment. Finding out your backups are empty during an incident is a specific and avoidable kind of bad evening.
I'm about to share this publicly. Stack: <stack>, live at <url>.
Here's the code: <paste or describe>
Go through it as the first stranger to arrive:
- Does it work on a phone, on a slow connection?
- What happens with unexpected input, or none?
- Any key, path or internal error message exposed?
- Can I read another user's data by changing an ID?
- Is anything unmetered that costs me money per call?
- Does a refresh or a back button lose someone's work?
- Do I find out if it breaks at 3am?
- What's the rollback if this goes badly?
Rank findings by how embarrassing they'd be, worst first.
Add a way for people to contact you before you launch, not after. The first bug report is worth more than the first hundred visitors.
Set up CI for my project. Repo on <GitHub / GitLab>. Stack: <stack>.
Keep it minimal:
- Run on push and on pull requests.
- Install dependencies from the lockfile, exactly.
- Run <tests / type check / lint> — say which are worth having and
which are noise for a project this size.
- Fail loudly, with output I can read without opening five sections.
- Cache dependencies so it isn't slow.
Don't add deployment yet. Then tell me roughly how long this will take
per run, and what it costs on the free tier.
Keep CI under a couple of minutes. A slow pipeline gets ignored, and an ignored pipeline is worse than none because it looks like coverage.
A second copy, as close to production as you can afford.
staging.txt
I deploy straight to production and I'd like somewhere to check first.
Stack: <stack>. Host: <host>. Budget: <what you'll spend>.
- Is a full staging environment worth it at my size, or would preview
deploys per branch do the job more cheaply?
- What must match production for the environment to be useful, and
what can differ?
- How do I get realistic data in without copying real users' personal
information?
- How do I stop staging sending real emails, charging real cards, or
hitting live third parties?
- How do I stop it being indexed by search engines?
Recommend the cheapest thing that would actually catch bugs.
Staging that sends real email is how customers receive your test messages. Route everything to a catch-all inbox before you use it once.
Decided in advance, because you won't think clearly then.
incident-plan.txt
My app: <describe>. Host: <host>. Users: <who they are>.
Write me a one-page incident plan:
- The first three things to check, in order, when something's wrong.
- How to tell "it's my code" from "it's the host" from "it's a
third party".
- The rollback command, exactly.
- What to tell users, where, and how quickly.
- What to capture before I start fixing, so I can work out the cause
afterwards.
Keep it short enough to follow at 3am. Then tell me what I should set
up now so this is easier later.
Capture the logs before restarting. Restarting often fixes it and destroys the only evidence of what happened.
From "works on my machine" to a live URL, in order.
first-deploy.txt
My project is <one sentence>, built with <stack>. It works locally. I want
it live on <host>.
Give me numbered steps for this specific host:
- What to upload or push, and where, and what must stay out.
- Setting the runtime version to match what I develop on.
- Creating the database and loading the tables, if I have any.
- Setting secrets and configuration on the host.
- Anything the host needs for routing to work.
- How to check it worked, beyond the home page loading.
Assume I've never used this host before.
"The home page loads" isn't a deploy test. Submit a form, trigger an error, and log in. Those are the paths that touch configuration.
Uptime checks and error alerts that fit this host.
alerts-on-host.txt
My site is <stack> on <host>. I only find out it's broken when someone
tells me.
Set up the minimum:
- An external uptime check against a page that touches the database, not
just the home page.
- Error reporting that emails me the real error and where it happened.
- An alert if my scheduled jobs stop running.
- One place I check each week to see everything is healthy.
Recommend free or cheap options that work with this stack, and what each
costs me to set up.
A check that loads your home page can pass while every other page fails. Point it at something that uses the database.
Everything that tends to go wrong with this stack on this host.
pre-launch.txt
I'm about to launch <one sentence>. Stack: <stack>. Host: <host>.
Here's the project: <paste the file list and key files>
Go through it as if you were a stranger arriving on launch day:
- Error display switched off in production, errors still logged.
- Secrets outside the web root and not in version control.
- HTTPS everywhere, with correct redirects.
- Backups running, and one restored as a test.
- Anything this host does differently from my machine that could bite.
- What happens if 200 people arrive in the same minute.
Rank the findings by how bad they'd be, worst first.
Launch day traffic arrives all at once, not spread across the day. Ask what happens at 200 visitors in a minute, not 200 a day.