Tell Claude to Follow an Existing File's Pattern When Creating New Ones
Every codebase has patterns — how controllers are structured, how services handle errors, how components organize their props. When you need a new file that fits in, point Claude at an existing one as the template.
"Create a ProductController following the exact same pattern as UserController"
Claude reads the referenced file, extracts the conventions — response format, error handling approach, validation style, method organization — and applies them to the new file. The result looks like it was written by the same developer on the same day.
This works for any kind of file:
# Components
"Create a ProductCard component following the pattern in UserCard.tsx"
# Services
"Write an OrderService following the same structure as PaymentService"
# Tests
"Write tests for the OrderController following the same style as UserControllerTest"
# Migrations
"Create a migration for the products table following the pattern of the orders migration"
# API Resources
"Create a ProductResource following the same structure as UserResource"
You can reference multiple files for more context:
"Create the full CRUD for products — controller, model, migration, tests, and routes —
following the same patterns used for the users module"
Claude reads all the user-related files and creates matching product files — same validation patterns, same response shapes, same test structure, same route grouping.
This is especially useful when:
- Onboarding — new team members create consistent code from day one
- Expanding features — adding a new resource type that should match existing ones
- Maintaining consistency — keeping the codebase uniform even as it grows
- Following team conventions — conventions that aren't documented but are visible in existing code
The best code standards aren't in a style guide — they're in the code itself. Point Claude at the example and it follows the pattern.
via Claude Code
Log in to leave a comment.
Before jumping to implementation, describe the problem conversationally and let Claude be your thinking partner. It asks clarifying questions, surfaces tradeoffs you haven't considered, suggests approaches, and pokes holes in your plan — so by the time you say "ok, build it," both of you know exactly what to build and why.
Paste error messages with "why did this fail?" instead of "fix this" to get Claude to diagnose the root cause before applying a fix.
When you need Claude to make changes in one area without affecting another, add negative constraints — "fix the bug but don't change the public API", "refactor the internals but don't create new files", or "update the logic but don't modify any tests." Explicit exclusions prevent Claude from making well-intentioned changes you'll have to undo.