How to edit your website with Claude, ChatGPT or Grok, with prompts you can copy

1. 01Never edit main directly. Every AI change goes on a branch and through a preview. This one rule makes everything else low-stakes.
2. 02One change per request. “Update the hours” is a good request. “Update the hours, redo the hero and fix mobile” is three, and you won’t know which one broke.
3. 03Ask for the whole file back, not a snippet. Pasting a full file is foolproof. Stitching a snippet into the right spot isn’t.
4. 04Paste errors back word for word. If the preview build fails, copy the error into the chat and ask what it means. Don’t describe it, paste it.
5. 05Never paste secrets. If a file has keys or passwords in it (usually one named .env), leave it out of the chat entirely.

AI is confident whether it’s right or not. The preview is where you find out which.

1. 01Find the file on GitHub that holds the thing you want to change (search for a phrase from the live page).
2. 02Click the copy icon above the file to copy its whole contents.
3. 03In Claude, ChatGPT or Grok, paste the file with one of the prompts below.
4. 04Copy the complete file it gives back.
5. 05On GitHub, click the pencil, select everything, paste, then Commit changes to a new branch and open a pull request.
6. 06Open the preview on your phone and a computer. If it’s right, merge.

The editing part is exactly the same flow as editing by hand, just with the assistant doing the typing. If any step there is new, go back to how to edit a file right on GitHub.

1. 01In your assistant’s coding tool, connect GitHub and give it access to only your site’s repository, not all of them.
2. 02Describe the change the same way you would in a chat, using a prompt below.
3. 03It reads the files, makes the change on a new branch, and opens a pull request.
4. 04Your host posts a preview link on that pull request. Check it on your phone.
5. 05Read what it changed in the pull request’s Files changed tab. Red is removed, green is added. Anything outside what you asked for is a reason to ask why.
6. 06Merge, or reply on the pull request with what to fix.

These are the ones we use. Fill in the brackets, paste the file underneath when you’re working in a chat, and send. The first rule for any of them is to be specific about what should not change, because that’s where assistants wander.

This is a page from my Next.js website. Change [the opening hours] from "[Tuesday to Saturday, 11 to 9]" to "[Wednesday to Sunday, 12 to 10]". Change only that text. Don't change layout, styling, class names or any other words. Give me back the complete file.

[paste the file here]

Add a new section to this page, directly after the section that starts with "[heading of the section before it]".

Heading: [your heading]
Text: [your paragraph, written out in full]
Button: "[button label]" linking to [/contact]

Match the style of the existing sections exactly: same spacing, same heading size, same button style. Reuse the class names already in this file instead of inventing new ones. Don't change anything else. Give me back the complete file.

On a phone about 390 pixels wide, [the three price cards are squeezed side by side and the text overlaps]. On desktop it looks right and should stay exactly as it is.

Fix it so on small screens [the cards stack one per row with space between them]. Use Tailwind's responsive prefixes (sm:, md:, lg:) and change as little as possible. Tell me in one sentence what you changed, then give me back the complete file.

I've uploaded a new photo to public/images/[new-file-name.webp]. In this file, replace the image [describe it, e.g. "of the old storefront"] with the new one, and change its alt text to: "[describe the new photo in one plain sentence]". Keep the same size and position. Give me back the complete file.

This is the [Services] page of my website for [what your business does, where]. Write the metadata for it: a title under 60 characters that starts with what someone would actually search for, and a description under 155 characters that says what's on the page and who it's for. Use only facts that are already on the page. Don't invent claims, numbers or awards. Add it as a metadata export at the top of the file and give me back the complete file.

My site's preview build failed. Here is the error, word for word:

[paste the full error from the build log]

And here is the file I changed last:

[paste the file]

Explain in plain English what went wrong, then give me the corrected complete file. Don't change anything that isn't part of the fix.

I'm not a developer. Explain what this file does on my website, in plain English, in five bullet points or fewer. Then tell me which parts are safe for me to edit by hand (words, links, images) and which parts I should leave alone.

[paste the file]

Add a new page to my Next.js site at /[services/catering]. Copy the structure and styling of app/[about]/page.tsx exactly.

Content, in this order:
1. Heading: [heading]
2. Intro paragraph: [text]
3. [list the sections, with their words written out]

Add the page's title and description metadata. Add a link to it in the main menu, after "[existing menu item]". Make a new branch for this and open a pull request. Don't change any other pages.

Every one of these follows the same shape: what to change, what not to touch, what to give back. If you want to know why that shape works so well, we tested it in how to write one prompt that gets a usable answer on the first try.

Write them down once, in the repository. Most coding assistants look for a plain text file at the top of the project, usually named AGENTS.md, and some also read their own (Claude’s is CLAUDE.md). Put your site’s house rules there and a connected or local assistant reads them before every change.

# House rules for this website

## About the business
[Business name] is a [what you do] in [where]. Our customers are [who].

## Voice
Plain, warm, short sentences. No jargon. No exclamation marks. Never invent facts, prices, reviews, awards or numbers.

## Brand
Colors: [hex codes and what each is for]. Fonts: [heading / body]. Reuse existing components and class names. Don't add new libraries.

## Safety
Work on a branch and open a pull request. Never commit to main. Don't touch .env files, next.config, or package.json unless asked. After changes, check the page at 390px wide and at desktop width.

If you find yourself explaining the same process over and over, that’s the moment to turn it into a skill the assistant finds on its own. Here’s how to turn a workflow you keep repeating into an AI skill.

1. 01The preview built. A green check on the pull request, not a red cross.
2. 02The change you asked for is there, on a phone and on a computer.
3. 03Nothing else moved. Scroll the whole page, not just the part you changed.
4. 04The Files changed tab only touches files you expected.
5. 05Every fact is true. Assistants love to add a confident sentence nobody asked for. Delete anything you didn’t say.

If a merged change turns out wrong, revert it. Two clicks, and the site is back. You can always undo.

AI assistants are excellent at small, well-described changes and unreliable at taste. A redesign, a new brand direction, or “make it feel more premium” will come back different, not better, and you’ll spend more rounds than a person would take.

They also don’t know your business. They’ll write a plausible testimonial, invent a year you were founded, or promise a turnaround you don’t offer. The house rules file cuts this down. Reading every line before you merge stops it.

And anything touching payments, logins, or customer data deserves a developer’s eyes, even if the AI’s version looks fine. Those are the mistakes that look fine right up until they don’t.