Agent prompts
Copy-paste prompts for Claude Code, Cursor or Codex that get your site ready for AI search, SEO, email and launch day.
Every prompt asks the agent to read your code, write a plan and stop. Nothing is edited until you approve.
Make your site readable by AI crawlers
Add llms.txt, markdown copies of key pages and robots.txt rules for AI search bots.
````text
I want AI assistants to be able to find and read this site. Look at how the site is built and which pages are public, then propose:
- An /llms.txt file: the product name, a one-sentence description, and a list of the most useful public pages with a short line about each.
- Markdown versions of the pages that explain the product (home, pricing, docs, FAQ), served at the same URL with .md added or through an Accept: text/markdown header, whichever fits this framework.
- robots.txt rules. Allow the bots that fetch pages to answer questions or power AI search (for example OAI-SearchBot, ChatGPT-User, PerplexityBot, Claude-SearchBot, Claude-User). Tell me which crawlers collect training data (for example GPTBot, ClaudeBot, Google-Extended, CCBot) and ask whether I want to allow or block them. Never block them without my answer.
- A sitemap that lists every public page, if one is missing.
Do not invent product facts. Take every claim from the existing pages and code, and flag anything you could not verify.
Work in two stages. First, read the repo and write a plan: the files you will create or change, and why. Then stop and wait for my approval. Edit nothing until I say go.
````
Fix titles, meta tags and canonicals
Give every public page a unique title, description, canonical URL and share card.
````text
Check the head of every public page in this repo for search and social sharing. For each page, report the current state of:
- the <title> (unique, under about 60 characters, names the page and the product)
- the meta description (unique, under about 160 characters, says what the page is for)
- the canonical URL (absolute, one per page, no tracking parameters)
- Open Graph and Twitter tags: title, description, image, URL and card type
- noindex on pages that should not be public, such as dashboards and checkout pages
- lang on <html> and a viewport meta tag
Then propose the smallest set of changes that fixes the gaps, using this framework's own head or metadata mechanism rather than adding a new library. If a share image is missing, tell me what size it needs. Do not rewrite copy I did not ask about: where a title or description is already fine, leave it.
Work in two stages. First, read the repo and write a plan: the files you will create or change, and why. Then stop and wait for my approval. Edit nothing until I say go.
````
Add JSON-LD from real data
Add structured data for your product, organization and FAQ, built from what the site already knows.
````text
Add schema.org structured data (JSON-LD) to this site. Use only facts that already exist in the code, config or content, such as the product name, URL, logo, description, pricing and FAQ answers. If a field would need a guess, leave it out and tell me.
Propose which types fit each page. Typical choices:
- Organization and WebSite on the home page
- SoftwareApplication (or Product, if it is not software) on the page that describes the product, with real offers only if a price is shown on the page
- FAQPage on a page that has visible question-and-answer content
- BreadcrumbList on nested pages
Generate the JSON-LD from the same data the page renders, so the two cannot drift apart, and escape the output so content cannot break out of the script tag. Do not add ratings, reviews or any claim that the page does not show. Tell me how to check the result with Google's Rich Results Test and the Schema.org validator.
Work in two stages. First, read the repo and write a plan: the files you will create or change, and why. Then stop and wait for my approval. Edit nothing until I say go.
````
Run a pre-launch audit
A read-only review of the repo that writes its findings to a file. It changes no code.
````text
Audit this repo as if I launch tomorrow. This is a read-only task: do not edit, create or delete any existing file, do not run migrations and do not call any production service. The only file you may create is LAUNCH-AUDIT.md in the repo root.
Before you start, tell me in a few lines what you plan to check, and wait for my approval.
Cover:
- Secrets and config: committed keys or tokens, .env files in git history, test keys used in production paths
- Auth and access: routes or API endpoints that skip auth checks, admin pages reachable without a login
- Input and output: unvalidated input, missing rate limits on signup, login and contact forms, unescaped user content
- Payments and email: webhook signature checks, idempotency, what happens when a payment or email call fails
- Errors and monitoring: unhandled errors, whether anything would tell me the site is down
- Pages: broken links, placeholder text, missing 404 page, missing favicon and share image
- Performance: oversized images, blocking scripts, large bundles
- Legal basics: privacy policy, terms and cookie notice if the site sets cookies
Write LAUNCH-AUDIT.md with the findings sorted into "Fix before launch", "Fix soon" and "Fine". For each one give the file and line, why it matters and the fix in a sentence. Mark anything you could not check, and do not pad the list with style opinions.
````
Add the Spotlighted badge
Add the badge that links to your listing and updates itself during and after your launch week.
````text
Add the Spotlighted badge to this site's footer, or to a "Featured on" or logos area if the site has one. Find where it fits the existing layout and match the surrounding styles.
The product id is YOUR_PRODUCT_ID and the product name is YOUR_PRODUCT_NAME. Replace every YOUR_PRODUCT_ID and YOUR_PRODUCT_NAME below with the real values before you write any code. If they are still placeholders, stop and ask me.
(To find the id: sign in to spotlighted.app, open your product from the dashboard, and copy the last part of its page address, spotlighted.app/product/<id>. Only the owner of an approved product sees the badge code on that page.)
Use exactly this embed. It is a plain link around an image, with no script. The image updates by itself: it says "Featured on", "Launching on" or "#N Product of the Week" depending on the state of the listing.
Light:
<a href="https://spotlighted.app/product/YOUR_PRODUCT_ID" target="_blank"><img src="https://spotlighted.app/api/badges/YOUR_PRODUCT_ID.svg" alt="YOUR_PRODUCT_NAME - Featured on Spotlighted" width="250" height="54" /></a>
Dark (use this on dark backgrounds):
<a href="https://spotlighted.app/product/YOUR_PRODUCT_ID" target="_blank"><img src="https://spotlighted.app/api/badges/YOUR_PRODUCT_ID.svg?theme=dark" alt="YOUR_PRODUCT_NAME - Featured on Spotlighted" width="250" height="54" /></a>
Markdown, for a README:
Rules: keep the 250 by 54 size, do not change the URLs, do not proxy or download the image, and add nothing that loads extra scripts. Use the dark version only if the page background is dark. Convert the markup to this project's component style (for example JSX) without changing the attributes.
Work in two stages. First, read the repo and write a plan: the files you will create or change, and why. Then stop and wait for my approval. Edit nothing until I say go.
````
Set up SPF, DKIM and DMARC
Find how your app sends email and list the exact DNS records that make it pass spam filters.
````text
My app sends email from my own domain and I want it to pass SPF, DKIM and DMARC so it lands in the inbox. Do not guess the setup:
- Search the repo and config for every way email is sent (Resend, Postmark, SendGrid, SES, SMTP, a newsletter tool) and for every From address and domain. List what you found.
- For each sending service, tell me what DNS records its documentation asks for. Give each record's type, host and value, with placeholders where the service generates the value for my account.
- Write one combined SPF record. A domain may have only one SPF record, so merge the services into a single TXT record and keep the total DNS lookups at 10 or fewer.
- Propose a DMARC record that starts at p=none with an rua address I can receive reports at, plus the steps for moving to quarantine and then reject once reports look clean.
- Check that the From address and the return-path domain align with the domain the DKIM key signs, which DMARC needs.
- Give me the commands to verify the result, such as dig for each record, and tell me how to send a test message and read the Authentication-Results header.
You cannot change my DNS, and you must not try. Write the records in a file named EMAIL-DNS.md for me to paste into my DNS provider. If you need to change code, for example a From address, include it in the plan.
Work in two stages. First, read the repo and write a plan: the files you will create or change, and why. Then stop and wait for my approval. Edit nothing until I say go.
````