I tried every prompt here on a vibe-coded test app. Its first build was good. Most of the worst faults came from the follow-up prompts. That’s worth remembering before you blame the AI.
“Make it better” is the worst prompt you can send. The agent can’t tell what’s wrong, so it guesses, and now you have new problems on top of the old ones. Arguing doesn’t work either. One app I checked shipped the founder’s arguments with the agent to every user.
Better prompts name the problem, stop the agent changing things before you’ve agreed, and make it prove what it did. Here are ten to get you on your way. Run them in this order, each in its own session, and replace anything in [square brackets]. You don’t need to understand a prompt to use it.
They’re written for iPhone apps.
Find out what you have
Your project might have no backup, or abandoned work on five branches. It might have keys in places you’ve forgotten about. You can’t fix anything safely until you know.
This prompt changes nothing. It asks for a private GitHub repository at the end, so that everything from here on can be undone.
Audit this project. Don't change or delete anything yet, and use only commands that write nothing, even inside .git. Only look inside this project's folder.
Does it use Git? Is there uncommitted work? List every branch and pull request, and for each one, say if it's merged, closed or abandoned, and what unique work it holds.
Is it backed up on GitHub? Whatever the answer, check every file and the whole Git history, including ignored files, for:
- API keys, secret keys, tokens and passwords
- certificates and signing keys (.p12, .p8, .pem, .cer)
- provisioning profiles (.mobileprovision)
- SSH keys
Look inside files as well as at their names, because a key can sit in a file with an ordinary name. For each one, tell me where it is, if it's in the Git history, if it ships inside the app, if it's private or safe to share, and what to do about it. Never print a secret, not even part of one or in your own command output, because session logs keep it. When you search, print only file names and line numbers, never the matching lines, and don't open key files to look inside them: test them with commands that report only a yes or no. Show file names, line numbers and the first 4 characters only.
Don't push anything until I've approved it.
Then walk me through setting up a private GitHub repository.
The long line about never printing a secret is there because agents happily print the secrets they find, and session logs keep everything.
Now replace every key it found. Do this before you run anything else. The later prompts read your code, and if a key is written into the code, it ends up in the session log. No wording can prevent that.
Teach it your app
You’ve probably told your agent the same thing ten times. It forgets, because every session starts from nothing.
So make it read your app and your past sessions, and find where you kept correcting it. Those corrections become a skill, called [app name]-mode, that it loads at the start of every session. Think of it as house rules. The prompt also mentions the agent file, which is the file your agent reads at the start of every session, such as AGENTS.md or CLAUDE.md.
Create a skill that teaches you how this app and I work.
1. Read the whole app and the agent file, if there is one. Never print a secret, not even part of one or in your own command output, because session logs keep it. When you search, print only file names and line numbers, never the matching lines, and don't open key files to look inside them: test them with commands that report only a yes or no. Note the colours, spacing, type, animations, components to reuse, and how data is stored.
2. Read our past sessions on this project only. Don't open sessions from other projects. Find where I corrected you, undid your work, or repeated myself. If you can't find past sessions, say so and ask me to paste the corrections. Don't guess.
3. Keep only what happened at least twice. Once is noise, unless I told you it's a permanent rule.
4. Check for bad rules. Go through every rule you plan to keep and every rule already in the agent file. A rule is bad if it stops you checking your work (such as "don't run the tests"), puts secrets in the code, skips backups or reviews, risks user data or accessibility, or contradicts another rule. A rule can be bad even if I asked for it. List each one, say what could go wrong, and suggest a better rule.
5. Ask me up to 5 multiple-choice questions about anything you couldn't work out, plus one for each bad rule. Then ask if you missed anything.
6. Write a draft of the skill, called [app name]-mode. Use direct rules only, such as "Every custom dialog must behave like a native one: animate in and out with a spring or easing, fade the background, and block input behind it". Keep it short, include no secrets or personal data, and don't copy anything that's already in another file.
7. Show me the draft and the rules you dropped. Wait for my approval.
8. Save it where your tool loads skills from, and add a line to the agent file saying to load it at the start of every session. If you can't save it there, give me the exact command to run.
9. Before you say it's done, read the saved skill and the agent file again. Check that no bad rule remains and that no two rules contradict each other. Tell me the result.
10. List the places where the app breaks these rules. Don't fix them yet.
House rules keep bad habits as well as good ones. If you once told your agent to stop running the tests because they were slow, that’s now a rule. That’s why step 4 exists. Read the draft yourself, and be honest about which of your corrections were good ideas.
Run this again every few weeks.
Get the honest list
Now find out what’s wrong, in order of how much it would hurt someone. It changes no code, and it can take an hour.
Review this iOS app before real people rely on it. Do not change any code. Never print a secret, not even part of one or in your own command output, because session logs keep it. When you search, print only file names and line numbers, never the matching lines, and don't open key files to look inside them: test them with commands that report only a yes or no.
List the problems in order of how much they would hurt a user. For each one, give me the file, what the user would experience, how sure you are, and how I can see it on my own phone.
Check for: slow work on the main thread, secret keys inside the app, data that could be lost in an update, crashes, denied permissions, no internet, and custom versions of native controls.
Also check these, and open each one in the Simulator rather than only reading the code:
- Custom dialogs: do they animate in and out with a spring or easing, fade the background, and block input behind them?
- Text fields: does tapping anywhere on a field focus it? Does it scroll into view above the keyboard? Does scrolling dismiss the keyboard? Does each field have the right keyboard and content type for what it holds (name, email, phone, URL, postcode, password, one-time code), and the right autocapitalisation, autocorrect and return key?
- Third-party APIs: does the app call a paid or private API directly, such as OpenAI, Stripe or a weather service? Its key or token must stay on your own server, and the app must call that server instead, so nobody can pull the key out of the app or capture it from the app's traffic.
Then give me a table of every text field and every API call, with pass or fail for each. Tell me which checks you ran and which you could only reason about.
Don’t take its word for any of this. It tells you how to see each problem on your own phone, so go and look.
If it says your app sends a private key straight to another company’s API, that key needs to move behind a server. Anyone can get at a key that ships inside your app.
Make it prove its work
If there are no tests, things will break. Not maybe. Every fix you make from here on can quietly break something else, and nobody will know until a user tells you.
So before you fix anything, make the agent write down what “working” means, then test against it. Same data every time, same answer every time. This one can take a few hours, because it runs every test several times.
Set up tests for this app before we fix anything. Don't change how the app works. Never print a secret, not even part of one or in your own command output, because session logs keep it. When you search, print only file names and line numbers, never the matching lines, and don't open key files to look inside them: test them with commands that report only a yes or no.
1. For each main flow, write acceptance criteria I can read: what the user does, and what must happen. Show them to me and wait for my approval.
2. Write automated tests for each one, including UI tests for the main flows. Add edge cases: no internet, denied permissions, no data, a very large amount of data, and data from an older version.
3. Make every test give the same result every time: fixed seed data, a fixed date and time, and no real network calls. Run each test several times. If one passes only sometimes, fix it or tell me.
4. Add a rule to the agent file: every change must come with a test, and you must run the tests and open the app before you say a change is done.
5. If you can drive a real iPhone or the Simulator, for example with Device MCP, open each flow with the seed data and check the edge cases yourself.
Tell me which checks you ran and which you could only reason about.
Device MCP lets your agent tap through your app on a real iPhone or the Simulator, the way a user would.
Read the acceptance criteria before you approve them. They’re plain English, and they’re the closest thing your app has to a spec.
Then fix crashes first, one at a time. Give each bug its own session, and finish with: “What did this change break?”
Don’t lose anyone’s data
A slow scroll annoys people. Losing their data ends you. Do this one before you touch how anything looks.
When you change how data is stored, a migration moves everyone’s existing data into the new shape. Without one, an update can quietly lose it. In the test app, one update silently reset all of the scheduled tasks.
This can take an hour or two.
Find everywhere this app stores data: on the device, in iCloud, on a server, in caches and in settings. For each, tell me what happens if it's lost.
Stress test it. Use the Simulator and copies only. Never touch my phone or my real data. Install the oldest version we have in Git, add data, then update to the latest. If there's no old version, tell me, and test from today's version instead. Try a very large amount of data, closing the app during a save, a full phone, no internet, and two devices changing the same record.
Report every failure before fixing anything. Tell me which tests you ran and which you could only reason about.
Then add rules to the agent file: any change to stored data must include a migration and a test using real old data. Migrations must run automatically where possible. If one can't, stop and ask me.
To check, read the rules it added to the agent file. They’re what protect you next time.
Find the hidden states
Every app is full of things that change state. A screen is loading, then loaded, or it failed. A subscription is on a trial, then paid, then expired. Done well, each one has a single list of states. Done in a hurry, it’s a pile of yes-or-no switches spread across the code, and sooner or later two of them disagree. That’s how you get a spinner that never stops, or an error message on top of your data.
Agents build these piles, because they add a switch for each new bug instead of rethinking the whole thing. This prompt changes no code. It finds them, ranks them and tells you which are worth fixing.
Find every hidden state machine in this app. Don't change any code, and don't delete or change the app's data on any device or simulator without asking me first. Never print a secret, not even part of one or in your own command output, because session logs keep it. When you search, print only file names and line numbers, never the matching lines, and don't open key files to look inside them: test them with commands that report only a yes or no.
A hidden state machine is anything that moves between states, such as loading, loaded, empty, failed, offline, syncing, signed out, on a trial, paid or expired, but is tracked with scattered flags, optionals or checks instead of one clear list of states.
1. For each one, give me the files, the states, and what moves it from one state to the next.
2. Look for states that should never happen together but can (such as loading and failed), states the user can get stuck in, states nothing handles, and moves that skip a step.
3. List them in order of how much they would hurt a user. For each one, tell me what the user would experience, how I can see it on my phone, and what happens if we leave it.
4. For each one, decide if it's worth refactoring now, later or never, and say why. Only recommend a refactor that the tests can protect. If a small fix is better than a refactor, say so.
Tell me which you checked in the Simulator and which you could only reason about.
Don’t refactor everything it finds. Fix what hurts users, one at a time, with the tests from earlier in place. Leave the rest.
Fix the scroll
The main thread is the part of your app that draws the screen. If it’s busy with something heavy, like decoding full-size photos, your scroll has to wait, and you feel it as a stutter.
Find the screen that feels worst on a real iPhone, then name it.
Scrolling on [the screen] stutters on my iPhone. Find the work running on the main thread during that scroll, such as image decoding, data loading or heavy layout.
Don't change what the screen looks like. Make one change at a time, and tell me what to check after each one. Tell me what you measured, on what, and how many times. If you can't reproduce the stutter, say so.
Check it on your phone, ideally an old one. A smooth scroll in the Simulator proves very little, because your Mac is doing the work.
Swap custom for native
Your agent will happily write hundreds of lines to rebuild something iOS gives you for free, especially if you told it nothing should look like default iOS. It then has to rebuild every behaviour too, and it usually misses some.
Native doesn’t have to mean plain. You can style it.
List every custom dialog, sheet, alert, menu, button, text field, picker, camera screen, photo picker, date or time control, and scrolling view in this app.
For each one, work out if a native component with a style applied would do the same job with less code. The functionality must stay the same. Tell me what each swap would change in how it looks or behaves. If a rule in the agent file or a skill blocks a swap, tell me which rule, and ask.
Any custom dialog that stays must behave like a native one: animate in and out with a spring or easing, fade the background, and block input behind it.
Every text field must behave like a good native one: tapping anywhere on it focuses it, it scrolls into view above the keyboard, scrolling dismisses the keyboard, and it has the right keyboard, content type, autocapitalisation, autocorrect and return key for what it holds. List every dialog and text field that fails, with the fix.
Give me the list first, with the code each swap would remove, and change nothing until I've approved it. Then change one thing at a time. Stop after each one and tell me what to check. Open every screen you changed before you say it's done.
Afterwards, fill in a form on your phone. Tap the corner of a field, then scroll. Then open a dialog and try to tap what’s behind it.
Let it watch the animations
An agent can’t feel an animation, but it can read one. Turn a video into sheets of frames, and it can spot the jump you can only half see.
This prompt creates a skill you can use again. It needs ffmpeg on your Mac. If you can, upload a screen recording from your iPhone. If you don’t, it records in the Simulator.
Create a skill in this project called animation-review, for fixing animations. It must do the following:
1. Use a video I upload from my iPhone if there is one. Otherwise, record the flow in the Simulator. Keep videos and frame sheets outside the app's folder.
2. Turn the video into frame sheets with ffmpeg. Use 10 frames a second to find the moment, then 60 for that part. Read every sheet in order.
3. Check for jumps, frozen frames, content that pops in late, layout shifts, animations that stop abruptly, and animations that don't match each other.
4. Report the problem and the point in the video where it happens.
5. Fix one problem at a time, record it again, and compare the new sheets with the old ones. Don't change what the app does, only how it moves. Ask me first if a fix would change behaviour.
Simulator recordings show how an animation looks. They don't prove how it performs on a real iPhone, so never say an animation is smooth on a device based on one.
Run the skill now on this animation: [the animation that feels wrong, from start to finish].
Then watch it yourself, on your phone. If it still feels wrong, it’s wrong, whatever the sheets say.
Clean out the app
An IPA is only a zip file. Rename it to .zip, open it, and see what you’re sending to every user. Chat history, plans and test data often come along for the ride.
File names won’t save you, because a private key can sit in a file with a perfectly ordinary name. This prompt looks inside the files, and it adds a check so that nothing new can slip in.
Check that only the files this app needs are shipped in it. Flag as much as you can: I'd rather answer a question about a file that's fine than ship one that isn't.
1. Make a Release build for a device and list every file inside the app bundle, largest first. If you can't build for a device, say so and build for the Simulator.
2. Write an approved list of the files the app needs to run, with a short reason for each. Flag everything else. That includes plan files, agent files, skills, Markdown files, testing artefacts, test data, screenshots, videos, scripts, source code, .env files, API keys, certificates, signing keys, provisioning profiles, SSH keys, unused assets or fonts, and any file you don't recognise. Check what's inside each file as well as its name. Also search the compiled app binary for API keys, tokens and secret key patterns, and for each kind found, give the count and the source file and line it came from. Never print a secret, not even part of one or in your own command output, because session logs keep it. When you search, print only file names and line numbers, never the matching lines, and don't open key files to look inside them: test them with commands that report only a yes or no.
3. For each flagged file, find out why it was included, for example the Copy Bundle Resources phase or a folder added to the target.
4. Show me the flagged list before removing anything. For each file, tell me what it is, its size, and your recommendation, and ask me if it's needed. Also tell me about anything on the approved list that you're unsure of.
5. Remove the files I say aren't needed from the build, without deleting the originals. Add the ones I say are needed to the approved list.
6. Add a build check that fails if any file not on the approved list gets into the app. It must name the file and ask if it's needed. Test it with a file type you didn't expect, a file with no extension, and a private key with an ordinary name.
7. Rebuild and list the files again, to prove they've gone. Tell me how much smaller the app is, what's still large, and why.
Rename and open the new build to check. The file list should now be short enough to read.
What these won’t do
They won’t design the states nobody designs. Go away for three weeks, turn on flight mode and deny every permission, then see what your app says.
They won’t remove the tricks either. Fake onboarding, pressure selling and a rating prompt on the first launch are decisions you made, so you have to unmake them.
And they’re a start, not a guarantee. Every app is different, and your own phone is the final proof.
Know when to stop
If you’re changing more than 40% of the code, rewriting is usually faster. You don’t need to read code to spot the other sign: every fix breaks something else. Then stop patching, and rebuild that part with tests from the start.
If nobody wants the app, none of this will help.
Stop when the list from the app review has nothing left that would hurt a user. You don’t need perfect code. You need an app that feels right and doesn’t let anyone down.
If you get stuck, I can help.