What it does: Writes one HTML file for a one page site with your headline, reasons, steps, and button.
Use it when: You need a simple site but have no time or coder.
You get: A single file that looks good on a phone, plus saved steps to reuse.
Open in
See the prompt
You are a web designer.
Business: [business]
Who it helps: [who]
With what: [what]
The one button: [button text] that goes to [link]
Look I like (don't copy it): [describe or link a site]
Build a one-page website as a single HTML file. The visitor is the hero, I'm the guide:
1. A big clear headline that says what they get. A stranger should get it in 5 seconds.
2. One line on the problem they have.
3. 3 short reasons to pick me.
4. A 3-step plan: how working with me goes.
5. One spot for a photo of the result.
6. The one button, near the top and at the bottom.
Rules:
- Short, simple words.
- Warm off-white background, thin grey lines instead of boxes and shadows.
- One color, only for buttons and links. The Inter font.
- No emoji as icons, and nothing that moves.
- It must look good on a phone.
- Fast to load. No extra libraries.
Last, save these steps as a skill called 'One Page Site' so you do it this way each time I ask to make a site.
Built from: Building a StoryBrand, Donald Miller, Chapter 3: The Simple SB7 Framework
What it does: Writes your page title, description and a sitemap so Google can read your page.
Use it when: Your page is live but no one finds it in search.
You get: Finished HTML with a checked heading and alt text, plus a ready sitemap file.
Open in
See the prompt
You are an SEO helper.
My page: [paste the HTML]
People find me by searching: [3 to 5 phrases]
Do this:
1. A page title under 60 characters that says what I offer, in the words people search.
2. A description under 155 characters: the problem I solve and how life is better after.
3. Share tags for links, and a favicon line.
4. Schema markup that says what my business is. Use only business details I gave you.
5. Check there's one H1, it says what I offer (not my history), and every image has alt text.
6. A sitemap.xml for these pages: [list your page links].
- Use only what is in my data. Do not make up hours, prices, image sizes, links, or file paths. Leave them out or write "confirm before publishing."
- Do not guess any image link or file path, like a logo or team photo. If I did not give it, write "confirm before publishing" in its place.
- Do not add any email address I did not give you. If one is needed, write "confirm before publishing."
- If something you need is missing, ask me for it.
Give me the finished HTML and the sitemap.
Last, save these steps as a skill called 'SEO Page Check' so you do it this way each time I add a page.
Built from: Building a StoryBrand, Donald Miller, Chapter 12: Building a Better Website
What it does: Writes your page words first, then builds a clean one-page HTML site with your colors and font.
Use it when: Your site looks like a template and you need it to look real.
You get: A single HTML file with your words, layout, and a picky designer check.
Open in
See the prompt
You are a senior web designer. Build my one-page website as a single HTML file that looks like a real company made it.
My business: [what you do, for who]
The one thing I want visitors to do: [button text] that goes to [link]
Sites I love the look of: [names or screenshots, like simpleai.community]
My color: [one main color, for buttons and links only]
My font: Inter
My pictures: [file names, or leave spots for them]
First write the words. The visitor is the hero, I'm the guide. Give me: a headline that says what they get, one line on their problem, a 3-step plan, and what life looks like after. A stranger should know what I offer, how it helps and how to buy in 5 seconds. Show me the words before you build.
Build it like this (the way simpleai.community is built):
1. A slim top bar: my name on the left, one main button on the right.
2. A centered headline, one short line under it, and 2 buttons: the main one filled, the second one outlined. The second button is a smaller first step, like a free guide.
3. A clean list of what I offer, like a library index: one row each, a thin grey line between rows, a short title and a small note on the right. No cards.
4. The 3-step plan, in one row or a short numbered list.
5. One picture only if it shows the result, not decoration.
6. A dark closing band with one short line and the main button.
7. A simple footer with my links.
Design rules (these make it look like a real company built it):
- Background: warm off-white, like #FAF9F7. No gradients, no glow, no grain.
- Thin grey lines (1px, about 10% black) to split things up. No boxes inside boxes, no shadows.
- One brand color, used ONLY on things people can click: buttons and links. Never on backgrounds, borders or plain text.
- One font: Inter. Headlines weight 700, letter spacing -0.015em, dark slate #292E34, not pure black. Body text 17px, grey #4B4A52.
- Only a few text sizes: 13, 15, 17 and 20px, plus one big headline size.
- Flat buttons: 40px tall, 6px corners, no glow, same size everywhere.
- No emoji as icons. Use real logos or nothing.
- Nothing moves: no slide-in animations, nothing that jumps on hover.
- Lots of empty space. Text columns no wider than about 720px.
- Short, simple words. No buzzword soup. Few words on the page. Every line is about the visitor.
- It must look great on a phone. No sideways scrolling.
- Fast. No extra libraries.
When it's built, act like a picky designer. List 10 things that look cheap, messy or AI-made (glows, gradients, emoji icons, cards in cards, too many colors or sizes), fix them all, and give me the final file.
Last, save these steps as a skill called 'Design My Site' so you do it this way each time I ask to design a site.
Built from: Building a StoryBrand, Donald Miller, Chapter 12: Building a Better Website
What it does: Walks you through Cloudflare Pages one click at a time, then points your domain at it.
Use it when: Your site is stuck on your laptop, not on the web.
You get: Step by step clicks, what you should see, and saved steps for next time.
Open in
See the prompt
You are a patient tech helper.
I have a website folder with an index.html file.
My domain: [domain], bought at [where you bought it]
Walk me through putting it live for free on Cloudflare Pages, one step at a time, for someone who has never done it. Then show me how to point my domain at it.
How to teach me:
1. First, tell me in 2 lines what we'll do and why.
2. One step at a time, with exactly where to click.
3. After each step, say what I should see.
4. If my screen looks different, stop and fix that first.
Rules:
- Wait for me to say done before the next step.
- Tell me what each step does in plain words.
- Add the custom domain in Cloudflare before the CNAME record.
- Use www, and forward the bare domain to it.
- Never tell me to delete DNS records I didn't make.
- Never ask me to paste a password or a token into the chat.
Last, save these steps as a skill called 'Put Site Live' so you do it this way each time I ask to put a site live.
Built from: Extreme Ownership, Jocko Willink and Leif Babin, Chapter 6: Simple
What it does: Writes the one prompt to paste into Lovable so it builds a simple page with your headline, 3 reasons, a 3 step plan and one booking button.
Use it when: You need a page for an offer this week and have no developer.
You get: A ready Lovable prompt, the page words, and a 5 point check for the page it builds.
Open in
See the prompt
You are my landing page writer, a senior copywriter who has written pages that book calls. You are a pro at this.
Goal: the page words, one Lovable prompt, and a 5 point check, so I can build the page today.
Context: my business needs a page that books calls. Visitors want to know what they get in 5 seconds.
First, check that you can read my answers below. Tell me which ones I gave. If one is missing, use its default, or ask me to paste it instead.
My offer: [what they get]
Who it's for: [who]
Their problem in their words: [one line]
3 reasons to pick me: [list]
The 3 steps to work with me: [list]
The button: [text] goes to [booking link]
One true proof: [a result, a number, a quote, or leave blank]
If I don't say, use these defaults: who = small business owners, steps = book a call, get a plan, start, button = Book a call, link = [check: booking link], proof = leave it out. Offer, problem and reasons have no default: write [check: offer], [check: their problem] or [check: reason] so nothing on the page is made up.
Ask me up to 3 questions only if the offer, who, or button link is missing. Then run.
1. Write the page words: headline (what they get, under 10 words), a subline, the problem, 3 reasons, the 3 step plan, proof if I gave one, and the button near the top and at the bottom.
2. Then write ONE prompt for Lovable that holds those words and says: one page, looks good on a phone, fast, one color for buttons, no stock photos of people, no sign-up, no other links.
3. Give me a 5 point check for the page Lovable makes: headline clear in 5 seconds, button in view on a phone without scrolling, words match, link works, nothing extra added.
Rules:
- The visitor is the hero. I'm the guide.
- No proof given? Leave the proof part out. Don't make one up.
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot, say so, and keep going.
- Never send, post, or change anything without my yes.
Before you show me, check:
- Check that every claim on the page came from my answers.
- Make sure the button shows near the top and at the bottom.
Last, save these steps as a skill called 'Lovable Landing Page' so you do it this way each time I make a landing page.
To run it again, just say: "Run my Lovable Landing Page skill."
Built on Building a StoryBrand's rule that the customer is the hero.
What it does: Reads a Hugging Face model card and tells you in plain words if you can use it for paid work, and what it's not good at.
Use it when: Someone tells you to use a free model and you don't know if the license allows it.
You get: Yes, no or check with a lawyer, the license in plain words, limits, and what to ask before you use it.
Open in
See the prompt
You are my model checker. This is not legal advice.
The model card: [paste the README from the model's Hugging Face page]
The license name on the page: [for example: apache-2.0, llama license, cc-by-nc-4.0]
How I want to use it: [for example: inside a paid app for my clients]
1. Say what the model does in 2 lines.
2. Say what the license lets me do, in plain words: paid use yes or no, changes yes or no, must I credit them, any user limits.
3. Answer: YES, NO, or CHECK WITH A LAWYER, for my use. One line why.
4. List what the card says it is bad at, or must not be used for.
5. List 3 things to test before I trust it with customers.
Rules:
- Only use what's in the card and the license name I gave. If the card doesn't say, write "the card doesn't say".
- "NC" in a license name means non-commercial. Say so if it's there.
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Check A Model' so you do it this way each time I check an open model.
Built from: Extreme Ownership, Jocko Willink and Leif Babin, Chapter 9: Plan
What it does: Searches Hugging Face Spaces for a free tool that does one job, like removing noise from audio, and checks each one before you upload anything.
Use it when: You need a quick tool for one job and don't want another paid app.
You get: Up to 3 Spaces with links, what to upload, last update, the license, and a privacy warning.
Open in
See the prompt
You are my tool finder. Search the web and huggingface.co/spaces.
The job: [for example: clean up background noise in a voice recording]
What I'll upload: [for example: a 2 minute phone call recording]
Private? [yes if it has customer data]
1. Find up to 3 Hugging Face Spaces that do this job. For each: the name, the link, what you upload, what you get back, when it was last updated, and its license.
2. Say if it looks like it's still working (recent update, recent likes or comments), or mark [check: may be asleep].
3. If my file is private, warn me: a public Space runs on someone else's setup, so use a fake or cleaned file to test first.
4. Pick one to try first, and say why in one line.
Rules:
- Only list Spaces you found a link for.
- Don't tell me to install anything.
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Find A Space' so you do it this way each time I need a free tool for one job.
Built from: The E-Myth Revisited, Michael E. Gerber, Chapter 18: Your Systems Strategy
What it does: Writes 5 test cases from your real work and a score sheet, so you can run 2 models side by side in Hugging Face's Inference Playground.
Use it when: You're picking an AI model for a job and every review says something different.
You get: 5 test inputs from your work, what a good answer looks like for each, and a score sheet.
Open in
See the prompt
You are my test planner.
The job: [what the model must do, for example: sort customer emails into 4 kinds]
5 real examples from my work: [paste them, with private details removed]
What a good answer must have: [for example: the right kind, and one line why]
1. Turn my examples into 5 test inputs. Make one easy, three normal, one hard.
2. For each, write what a good answer looks like.
3. Write one system message to use for both models, under 60 words.
4. Make a score sheet: test number, model A score 0 to 2, model B score 0 to 2, notes. 0 = wrong, 1 = close, 2 = right.
5. When I paste the answers back, score them, add it up, and say which model wins and where each one failed.
Rules:
- Same system message and same settings for both models.
- Score only on what a good answer must have.
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Test Two Models' so you do it this way each time I pick a model for a job.
Built from: The Sales Acceleration Formula, Mark Roberge, Chapter 7: Metrics-Driven Sales Coaching
What it does: Writes the prompt for v0 by Vercel to build a short quote request page that asks only what you need and tells people what happens next.
Use it when: Your contact form asks too much or too little, and good leads don't finish it.
You get: One v0 prompt, the questions to ask, the thank you message, and a check list before you put it live.
Open in
See the prompt
You are my form planner. I'll build it in v0 by Vercel.
What people ask me to quote: [your service]
What I need to give a quote: [the fewest facts you really need]
What happens after they send it: [for example: I call within 1 business day]
Where answers should go: [for example: my email, or my CRM]
1. Pick the 5 or fewer questions I need. Say why each one is needed. If what happens next needs a phone number, make phone required.
2. Write the page words: headline, one line on how fast I answer, the questions, the button, and a thank you message that says exactly what happens next.
3. Write ONE prompt for v0: one page, phone first, the questions, required fields marked, a thank you screen, no log in. Ask v0 to send answers to the place I named, and to tell me what I need to set up for that.
4. A check list before going live: test it on a phone, send 2 test answers, check they arrive, check the thank you message.
Rules:
- No question I don't need to quote.
- Promise only the response time I gave.
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Quote Form Page' so you do it this way each time I make a quote request page.
Built from: The Sales Acceleration Formula, Mark Roberge, Chapter 11: Converting Inbound Interest into Revenue
What it does: Walks you through linking your own domain to your Vercel site, step by step, in plain words, for where you bought the domain.
Use it when: Your site works on a vercel.app link but not on your own domain.
You get: Numbered steps for Vercel and your domain company, what to check after, and what to do if it doesn't work.
Open in
See the prompt
You are my setup guide.
My domain: [for example: mybusiness.com]
Where I bought it: [for example: GoDaddy, Namecheap, Cloudflare]
Does the domain have email set up on it now? [yes or no]
Do I want www or no www as the main one: [pick one]
1. Write numbered steps in Vercel: open the project, Settings, Domains, add the domain. Tell me Vercel will show the exact records to add, and to copy those, not ones from a blog.
2. Write numbered steps for my domain company: where the DNS page is, and how to add or change the records Vercel showed.
3. If I have email on the domain: warn me not to touch the MX records or email records.
4. What to check after: the Vercel domain page says it's set up, the site loads on both www and no www, the lock icon shows.
5. If it doesn't work after a few hours: the 3 most likely reasons and what to check.
Rules:
- Don't make up record values. Say "the value Vercel shows you".
- Never ask me for a password.
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Domain On Vercel' so you do it this way each time I put a site on my own domain.
Built from: Extreme Ownership, Jocko Willink and Leif Babin, Chapter 9: Plan
What it does: Writes the prompt for Lovable to build a small app where your crew sees today's jobs, marks them done and adds a photo.
Use it when: Jobs live in texts and a whiteboard, and things get missed.
You get: One Lovable prompt, the screens and fields, who can see what, and 6 tests to run before the crew uses it.
Open in
See the prompt
You are my app planner. I'll build it in Lovable.
My business: [what you do]
Who uses it: [for example: me and 4 crew members]
What a job has: [for example: customer, address, date, what to do, notes]
What the crew does: [for example: see their jobs, mark done, add a photo]
1. List the screens: for the crew, and for me.
2. List the fields for a job, and which are required.
3. Say who can see and change what: crew see only their own jobs, I see all.
4. Write ONE prompt for Lovable with all of this. Ask for: log in, phone first, big buttons, a "Today" view, a "Done" button that saves the time, photo upload.
5. Write 6 tests: crew can't see another person's job, a photo saves, done time saves, I can add a job, it works on a phone, log out works.
Rules:
- Keep it to what I listed. No chat, no payments, no maps, no extra fields unless I ask.
- The Lovable prompt uses the same plan, word for word where it can.
- If you have to pick something I didn't give you (a name, a time, a setting, a day), mark it (suggested).
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Job Tracker App' so you do it this way each time I build a job tracker.
Built from: The E-Myth Revisited, Michael E. Gerber, Chapter 18: Your Systems Strategy
What it does: Turns 'it's broken' into one clear fix request for Lovable, so it changes one thing and doesn't break the rest.
Use it when: You ask Lovable to fix something and it changes 5 other things.
You get: One fix prompt for Lovable, what to check after, and how to undo if it goes wrong.
Open in
See the prompt
You are my fix writer for Lovable.
What I did: [the steps you took]
What I expected: [what should happen]
What happened: [what did happen, any error text]
Which page: [the page name or link path]
1. Write ONE fix prompt for Lovable that has: the page, the steps, expected vs what happened, the error text, and the line "Change only what's needed to fix this. Don't change the layout, colors or other pages."
2. If I listed more than one problem, write one fix prompt for each, each with the same parts, and tell me to send one at a time, biggest first.
3. Tell me what to check after the fix, in 3 lines.
4. Remind me how to go back to the last working version in Lovable's history if the fix breaks something.
Rules:
- Use my words for what happened. Don't guess the cause in the prompt.
- If a problem is missing a detail (what I expected, error text), write [check: that detail].
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Lovable Fix Request' so you do it this way each time I ask Lovable to fix something.
Built from: Extreme Ownership, Jocko Willink and Leif Babin, Chapter 6: Simple
What it does: Reads how your project is set up and writes a short Cursor rules file, so its changes match your code and don't touch what they shouldn't.
Use it when: Cursor keeps adding new libraries, renaming things, or editing files you didn't ask about.
You get: A rules file under 40 lines, where to save it, and 3 test asks to see if Cursor follows it.
Open in
See the prompt
You are my setup helper, inside my project in Cursor.
What the project is: [one line, for example: my business website]
What must never change: [for example: the payment page, the .env file]
How I like changes: [for example: small, one file at a time, explain first]
1. Look at the project: the language, the framework, how files are named, how it's tested, how it's run.
2. Write a rules file under 40 lines:
- what the project is and what it uses
- naming and file rules you can see in the code
- never add a new library without asking
- never touch the files I said must never change
- my change rules, in my words
- run the tests (or say there are none) after each change
3. Tell me where to save it in this project for Cursor to use it.
4. Give me 3 test asks to check Cursor follows the rules.
Rules:
- Only write rules you can see in the code or that I gave you.
- If you have to pick something I didn't give you (a name, a time, a setting, a day), mark it (suggested).
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Cursor Rules' so you do it this way each time I set up Cursor on a project.
Built from: The E-Myth Revisited, Michael E. Gerber, Chapter 8: The Franchise Prototype
What it does: Writes a fix request that makes Cursor find the cause first, show you the plan, then change as little as it can.
Use it when: You asked for a small fix and got 12 changed files.
You get: A fix request for Cursor, the plan it should show you, and a check list before you accept the change.
Open in
See the prompt
You are my bug fix helper, inside my project in Cursor.
The bug: [what's wrong, in plain words]
How to make it happen: [steps]
What should happen: [expected]
Any error text: [paste]
Do this, in order, and stop after step 2 until I say go:
1. Find where the bug comes from. Show me the file and the lines, and why you think so.
2. Show me your fix plan: which files you'll change, what you'll change, and what you won't touch. Smallest change that fixes it.
3. After I say go, make only that change.
4. Tell me how to test it, step by step.
5. List anything else you noticed but didn't change.
Rules:
- No new libraries. No renaming. No style changes.
- If you're not sure of the cause, say so and tell me what to check.
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Fix One Bug' so you do it this way each time I ask for a bug fix.
Built from: Extreme Ownership, Jocko Willink and Leif Babin, Chapter 7: Prioritize and Execute
What it does: Has Codex read your project and write a short AGENTS.md: how to run it, test it, and what not to touch.
Use it when: Codex keeps guessing how your project works and gets it wrong.
You get: An AGENTS.md under 50 lines, plus what Codex couldn't figure out and needs from you.
Open in
See the prompt
You are my setup helper, with access to my project.
What the project is: [one line]
What must never change: [files or folders]
Who works on it: [for example: just me, plus Codex]
1. Read the project: language, how to install, how to run, how to test, folder layout.
2. Write an AGENTS.md under 50 lines with:
- what the project is
- the exact commands to install, run and test, only ones you checked in the files
- the folder map, one line each
- the rules: small changes, run the tests, never touch the files I named, no new libraries without asking
3. List what you couldn't figure out (for example: no test command found) as questions for me.
4. Show me the file. Don't save it until I say yes.
Rules:
- Only commands you can find written in the project's files. If there's no install command written down, write [check: install command].
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Write AGENTS.md' so you do it this way each time I set up Codex on a project.
Built from: The E-Myth Revisited, Michael E. Gerber, Chapter 8: The Franchise Prototype
What it does: Turns a feature idea into one Codex task with what done looks like, the files in play, and the tests it must pass.
Use it when: You give Codex a big vague ask and get back something you can't use.
You get: One task brief for Codex, a done check list, and what to review in its change.
Open in
See the prompt
You are my task writer for Codex.
The feature, in my words: [what you want]
Who uses it and why: [one line]
Where it lives in the app: [page or file if you know]
1. Cut it down to the smallest piece that's useful on its own. If it's big, split it and give me the first task only.
2. Write the task brief:
- Goal in one line
- What done looks like, 3 to 5 checks a person can see
- Files likely to change, and files not to touch
- Tests to add or update
- Out of scope, in 2 lines
3. Write what I should look at when I review Codex's change.
Rules:
- One task, one change. No "and also".
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Codex Task' so you do it this way each time I give Codex a task.
Built from: Extreme Ownership, Jocko Willink and Leif Babin, Chapter 6: Simple
What it does: Has Codex read a change and explain what it does, what could break, and how to test it, in words a non-coder gets.
Use it when: Someone (or an AI) changed your code and you have to say yes without fully getting it.
You get: What changed in plain words, the risks, a test list, and MERGE, FIX FIRST or ASK.
Open in
See the prompt
You are my code reviewer, with access to my project.
The change: [the pull request or branch name]
What it was meant to do: [one line]
1. Explain what changed in plain words, under 100 words. No code words without a short meaning.
2. Does it do what it was meant to do? Yes, partly or no, and why.
3. What could break: list each risk, and how likely (low, medium, high).
4. Anything that touches money, log ins, customer data or deleting: flag it first.
5. A test list I can follow by clicking around, step by step.
6. Say MERGE, FIX FIRST (with what) or ASK (with the question for the person who wrote it).
Rules:
- Don't change any code. Only read and explain.
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Explain This Change' so you do it this way each time I review a code change.
Built from: Extreme Ownership, Jocko Willink and Leif Babin, Chapter 1: Extreme Ownership
What it does: Sets up a fair test in OpenRouter's chat room: same task, same input, 3 models, and a score sheet to pick the cheapest one that passes.
Use it when: You pay for the biggest AI model for a small job and don't know if a cheaper one would do.
You get: A test prompt, 5 inputs from your work, a score sheet, and how to read the price per model.
Open in
See the prompt
You are my test planner.
The job: [for example: write a 2 line summary of each call note]
5 real inputs: [paste them, with private details removed]
What a pass looks like: [for example: under 40 words, has the next step and date]
Models to try: [3 models, or "you pick 3: one big, one middle, one small"]
1. Write one prompt for the job, under 80 words, that I'll use for all 3 models.
2. Make a score sheet: input number, model, pass or fail, why.
3. When I paste the answers back, score them against what a pass looks like.
4. Tell me which models passed all 5, and to check each model's price on its OpenRouter page. Pick the cheapest one that passed.
Rules:
- Same prompt and same inputs for every model.
- Don't quote model prices from memory.
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Pick A Model' so you do it this way each time I pick an AI model for a job.
Built from: Fanatical Prospecting, Jeb Blount, Chapter 6: Know Your Numbers
What it does: Uses the prices you copy from OpenRouter's model pages and your real volume to estimate the monthly cost of an AI job.
Use it when: You're about to automate something with AI and have no idea what it will cost.
You get: The cost per run, per day and per month for each model, the math shown, and a safe monthly cap to set.
Open in
See the prompt
You are my cost checker.
The job: [what the AI does each time]
How many times a day: [number]
A typical input: [paste one, or say how long: for example, a 300 word email]
A typical output: [how long the answer is]
Models and prices from OpenRouter: [model name, input price per 1M tokens, output price per 1M tokens]
1. Estimate tokens: about 4 characters or 0.75 words per token in English. Show the input and output tokens for one run.
2. Work out the cost of one run for each model. Show the math.
3. Multiply for a day and a 30 day month.
4. Add 30% for retries and longer inputs, and say that's a cushion, not a fact.
5. Suggest a monthly spending cap for each model's key: the cushioned month, rounded UP to the next whole dollar.
Rules:
- Use only the prices I pasted.
- Keep full numbers until the end. Show one run to 4 decimal places and a month to the cent. Then round the cap up.
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'AI Cost Math' so you do it this way each time I price an AI job.
Built from: Up the Organization, Robert Townsend, Budgets
What it does: Makes a plan for your OpenRouter keys: one key per app, a credit limit on each, and what to check every week.
Use it when: One AI key runs everything and a bug could spend your whole balance overnight.
You get: A key list with names and caps, steps to set them in OpenRouter, and a weekly 5 minute check.
Open in
See the prompt
You are my safety planner for AI keys.
Where I use AI: [list each app or automation, for example: website chat, inbox sorter, call notes]
What each costs a month, roughly: [amounts, or "don't know"]
My total monthly budget for AI: [amount]
1. Make a key list: one key per app. A clear name for each, like "inbox-sorter".
2. Set a credit limit for each: its monthly cost plus a cushion, and all of them adding up to under my budget. Every key with a cost I don't know gets a small starting cap marked [check after 1 week].
3. Steps to do it in OpenRouter: make a key on the Keys page, set its credit limit, copy it once into that one app's settings.
4. A weekly 5 minute check: which key spent the most, any jump from last week, any key not used in 30 days to turn off.
5. What to do if a key leaks: turn it off in OpenRouter first, then make a new one.
Rules:
- Never ask me to paste a key here.
- Mark any cap or cushion you pick (suggested).
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'AI Key Caps' so you do it this way each time I set up or check my AI keys.
Built from: Extreme Ownership, Jocko Willink and Leif Babin, Chapter 9: Plan
What it does: Writes the prompt for Replit Agent to build a small app where new customers fill in their details once and you see them in a list.
Use it when: You collect the same customer details by phone, text and email, and copy them by hand.
You get: One Replit Agent prompt, the fields, the screens, and 6 tests before you share the link.
Open in
See the prompt
You are my app planner. I'll build it with Replit Agent.
My business: [what you do]
What I need from a new customer: [the fields]
What happens after they submit: [for example: they see a thank you, I get an email]
Who sees the list: [just me]
1. List the fields, which are required, and why each is needed.
2. List the screens: the customer form, the thank you, and my list (behind a log in).
3. Write ONE prompt for Replit Agent: phone first, a database for answers, my list behind a log in only I can use, an email to me on each new entry, any keys in Secrets.
4. 6 tests: form saves, required fields stop a blank form, my list needs a log in, a customer can't see other customers, the email arrives, it works on a phone.
Rules:
- No payment, no customer accounts.
- Ask for only the fields I listed.
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Intake App' so you do it this way each time I build an intake form app.
Built from: The Sales Acceleration Formula, Mark Roberge, Chapter 11: Converting Inbound Interest into Revenue
What it does: Writes the prompt for Replit Agent to turn your weekly CSV export into a simple page with the 5 numbers you care about.
Use it when: You open a spreadsheet every Monday and do the same math by hand.
You get: One Replit Agent prompt, the 5 numbers and their exact math, and test data to check it.
Open in
See the prompt
You are my app planner. I'll build it with Replit Agent.
My CSV columns: [list them, for example: date, rep, calls, conversations, meetings, deals won, amount]
The numbers I want each week: [up to 5]
Who looks at it: [me, or the team]
1. Write each number's exact math in plain words, like "meetings divided by conversations".
2. Write ONE prompt for Replit Agent: upload a CSV, show the 5 numbers for the week, a small chart of the last 8 weeks, a table by rep, no log in if only I use it on my own link (say so), no outside data.
3. Make a sample CSV of 10 rows with fake names, and write the right answer for each number so I can test the app.
Rules:
- Use my math only. If a number could divide by zero, show "n/a".
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Sales Numbers Page' so you do it this way each time I build a numbers page.
Built from: Fanatical Prospecting, Jeb Blount, Chapter 6: Know Your Numbers
What it does: Goes through your Replit app with you before anyone else uses it: keys, test data, log in, and what happens on a phone.
Use it when: You built an app that works for you and you're about to send the link to customers.
You get: A pass or fix list, the exact fix for each fail, and a short note on what to watch the first week.
Open in
See the prompt
You are my launch checker, inside my Replit project.
What the app does: [one line]
Who will use it: [customers, staff]
Does it store personal details? [yes or no, which ones]
Check each and mark PASS or FIX, with the file and line for any FIX:
1. Keys and passwords live in Secrets, not in the code.
2. Test or fake data is removed from the live database.
3. Pages that should need a log in really do. Try the address without logging in.
4. A user can't see another user's data by changing a number in the link.
5. Forms handle blank and silly input without crashing.
6. It works on a phone screen.
7. It's on a deployment, not the test preview link.
8. Errors don't show code or keys to the user.
Then the exact fix for each FIX, smallest first, and what to watch the first week.
Rules:
- Don't change anything until I say yes to each fix.
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Launch Check' so you do it this way each time I'm about to share an app.
Built from: Extreme Ownership, Jocko Willink and Leif Babin, Chapter 9: Plan
Simple AI
Hugging Face
Vercel
Lovable
Cursor
Codex
OpenRouter
Replit
Google Antigravity
Supabase
Wix
Framer
Base44
Webflow
Bolt
Cloudflare Pages
Squarespace Domains
v0
MarketingRun the business
