# Build something new from an existing pattern

Point Claude Code at code that already works the way you want, so the new feature matches its structure, naming, tests and error handling.

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
Look at how {{example}} is implemented to understand the pattern, then build the following the same way:
{{build}}
{{#differences}}

Where it should differ from the example:
{{differences}}
{{/differences}}

Before writing code, describe the pattern in a few lines: file layout, naming, how errors are handled, how it is registered or wired up, and how it is tested. If the example is inconsistent with the rest of the codebase, tell me which one you will follow. If you cannot find the example, or it does not cover part of what I asked for, say so and ask before you fill the gap yourself.

Then:
- Reuse the helpers and libraries the example already uses. Do not add new dependencies.
- Add tests in the same style as the example's tests, including its error cases.
- Run the tests that cover the new code{{#check}} with: {{check}}{{/check}}. Show me the command and the result, and keep working until they pass.

Finish with a list of the files you added or changed, and anything you did differently from the example and why.
```

## Fields

- `{{example}}` (required): Existing code to follow. A file, class or feature that is a good model. In Claude Code you can type @ to reference a file.
- `{{build}}` (required): What to build.
- `{{differences}}`: Where the new code should differ. Optional. Anything the example does that the new code must not copy.
- `{{check}}`: Command that checks the result. Optional. Leave empty and Claude will look for the tests that cover the example.

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

- The project already has a feature that works the way the new one should, such as another handler, widget, endpoint or job of the same kind.
- Consistency matters more than novelty: you want the new code to look as if the same person wrote both, so reviewers and future readers find it where they expect.
- You are new to the codebase and do not yet know its conventions well enough to describe them yourself.

## When not to use it

- The existing code is the thing you want to get away from. Copying a pattern you plan to replace spreads it further; use the migration template instead.
- There is no close example. Pointing at something only loosely related produces code that copies the wrong details; plan the change instead.
- The task is in a plain chat without file access. Paste the example code and use a regular coding prompt, because Claude cannot open the file by its name.

## Why this structure

- Naming a concrete example is a direct way to convey conventions. One working file carries naming, layout, error handling and test style in a form Claude can read, which a description rarely does.
- Asking Claude to describe the pattern before writing code makes its reading visible. You can correct a misunderstanding in one line before it is repeated across several files.
- The differences field covers the details the example gets right for its own case but wrong for yours, which is where copied code most often goes astray.
- The rule against new dependencies keeps the new code within what the project already uses, as the example does.
- The tests line, with your command when you give one, gives Claude a check it can run and a reason to keep going until it passes, instead of stopping when the code looks finished.

## Example input (fictional)

Existing code to follow:

```
the GitHub webhook handler in src/webhooks/github.ts
```

What to build:

```
A webhook handler for payment events that records refunds and ignores event types it does not know.
```

Where the new code should differ:

```
Payment events are signed with an X-Pay-Signature header instead of X-Hub-Signature-256.
```

Command that checks the result:

```
npm test -- webhooks
```

## Follow-ups to send Claude

- Compare the new handler with the example side by side and list every place they differ. Is each difference intended?
- The example has no test for a malformed payload. Add one for both handlers.
- Write the pattern you described into CLAUDE.md in three or four lines, so later work follows it without being told.

## Common mistakes

- Choosing an example that is old or atypical. If the codebase has two styles, name the one you want to keep, or Claude may copy the one you are phasing out.
- Leaving out the differences. Claude will then copy details that only made sense for the example, such as its header name or its table.
- Skipping the pattern summary and going straight to code. The summary costs one short reply and lets you check Claude's reading of the example before any code is written.

## Related templates

- [Write tests first, then implement](https://awesomeclaudeprompts.com/prompts/test-first-feature/): Have Claude Code write tests that describe a feature before any implementation, confirm they fail, then write code until they all pass.
- [Generate docs for undocumented code](https://awesomeclaudeprompts.com/prompts/generate-code-docs/): Have Claude Code find functions or classes without doc comments and add them in the format and style the file already uses, changing no code.
- [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.

## Sources

- [Claude Code docs: Prompt library](https://code.claude.com/docs/en/prompt-library) (Anthropic documentation)
- [Claude Code best practices: Provide specific context in your prompts](https://code.claude.com/docs/en/best-practices#provide-specific-context-in-your-prompts) (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)

---

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.