# Find and update copy across the codebase

Have Claude Code find a phrase and its near variants across the project, show each one in context, then change the wording while leaving tests alone.

Paste into: **Claude Code**, started in your project folder

## Prompt template

How the builder on the page fills in this template, so you can do the same:

- `{{key}}` becomes the text entered for that field, exactly as typed. Empty text, or text that is only whitespace (spaces, tabs or line breaks), counts as empty: a required field then becomes `[fill in: <label>]` with its label, and an optional field becomes nothing.
- For a choice field, `{{key}}` becomes the text of the chosen option, or of the default when none is chosen.
- Text between `{{#key}}` and `{{/key}}` stays only when that field is not empty; a choice field always counts as filled. The markers themselves are removed, and a marker that stands alone on its line takes its line break with it.
- Each value is inserted once, as it is: `{{…}}` inside a value stays as typed.

```text
Find every place we say "{{copy}}" or a close variant, and change it to "{{new}}". Leave tests and the changelog alone.{{#skip}} Also leave these alone: {{skip}}{{/skip}}

1. Search the whole project: UI strings, templates, translation files, emails, docs and config. Include close variants, such as other capitalization or punctuation, a word added or dropped, or the phrase split across lines or built from string pieces.
2. Show me each match in context: file, line and the surrounding sentence. List exact matches and variants separately. Mark any place where the new wording may not fit, such as a button with little room, a sentence whose grammar would break, or text in another language.
3. When the list is ready, {{mode}}.
4. When you edit, change only the wording. Match the capitalization the surrounding text uses. Do not rename keys, IDs or file names. Do not translate text yourself; list translated matches for me instead.
5. If a match uses the phrase in a different sense, or you are unsure whether it should change, ask instead of guessing.
6. After editing, search again for the old wording and its variants. Run the build or tests if the project has them. If a test fails only because it expects the old wording, report it and do not edit the test. Do not commit.

Finish with the files you changed, the matches you left unchanged and why, and anything you were unsure about.
```

## Fields

- `{{copy}}` (required): Current wording.
- `{{new}}` (required): New wording.
- `{{skip}}`: Also leave alone. Optional. Tests and the changelog are always left alone. Add any other files or folders that must keep the old wording.
- `{{mode}}`: After the list of matches. Choose one:
  - stop and wait for my go-ahead before you edit anything (default)
  - go ahead and update them all

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

## When to use this template

- A label, button text, product name or call to action has changed, and the old wording is spread across components, pages, emails and docs.
- The phrase appears in slightly different forms in different places, so a single exact find and replace in your editor would leave some of them behind.
- You work on design, docs or marketing and want to review every visible change before it lands, without reading the code yourself.

## When not to use it

- The wording lives in a content management system or a translation service rather than in the repository. Claude Code can only change the files it can read; update it there instead.
- You want to rename a code identifier, such as a function, variable or database column. That is a refactor with different risks; plan it as a code change instead.
- The new wording still needs approval from someone else. Settle the text first, then run this once, so the project is not edited twice.

## Why this structure

- The opening line names the old and new wording and the default exclusions in one sentence, so the scope is clear before Claude searches anything.
- Step 1 spells out what counts as a close variant. Without that list, a search tends to stop at exact matches and leave the variants behind.
- Step 2 asks for each match in context, with exact matches and variants listed apart. That lets you reject a match that uses the same words in a different sense before anything is edited.
- The setting in step 3 decides whether Claude pauses after the list. The default waits for you, which suits wording that has to be checked by someone else.
- Step 6 searches again after editing and runs the project's checks. The search reports any matches that remain, the tests report failures in the code they cover, and a separate rule says what to do with tests that expect the old text.
- The closing report lists what was left unchanged and why, which is the part you most need to check in a change like this.

## Example input (fictional)

Current wording:

```
Sign up free
```

New wording:

```
Start free trial
```

Also leave alone:

```
the archived blog posts under content/blog/2023/
```

After the list of matches:

```
stop and wait for my go-ahead before you edit anything
```

## Follow-ups to send Claude

- Show me the full diff of the wording changes, grouped by page or component.
- Which tests still expect the old wording? List them with file and line, but do not change them yet.
- Search the translation files for the same message key and tell me which languages still use the old meaning.

## Common mistakes

- Asking for the change without the exclusions. Test fixtures and changelog entries often contain the old wording on purpose, and editing them rewrites history or breaks tests.
- Letting Claude edit before you have seen the list. A phrase can mean different things in different places, and the list is the cheap moment to catch that.
- Relying only on rewind to undo a bad edit. Checkpoints cover Claude's file edits but not changes made through shell commands, so commit or stash your own work before you start.

## Related templates

- [Edit a draft for clarity](https://awesomeclaudeprompts.com/prompts/edit-for-clarity/): Make a draft clearer for a named reader while keeping your meaning and voice, with a short list of what changed and why.
- [Migrate a pattern across a codebase](https://awesomeclaudeprompts.com/prompts/migrate-code-pattern/): Move every use of an old API, library or pattern to its replacement: Claude Code lists each place first, then changes them in checked batches.
- [Review your changes before you commit](https://awesomeclaudeprompts.com/prompts/review-before-commit/): Have Claude Code review uncommitted changes against their intent and flag risks by severity, asking before any check that could change files.

## Sources

- [Claude Code docs: Prompt library](https://code.claude.com/docs/en/prompt-library) (Anthropic documentation)
- [Claude Code best practices: Give Claude a way to verify its work](https://code.claude.com/docs/en/best-practices#give-claude-a-way-to-verify-its-work) (Anthropic documentation)
- [Claude Code best practices: Rewind with checkpoints](https://code.claude.com/docs/en/best-practices#rewind-with-checkpoints) (Anthropic documentation)

---

Awesome Claude Prompts is an independent project. It is not affiliated with, endorsed by, or sponsored by Anthropic. Claude is a trademark of Anthropic, PBC.