Ask Claude to Scaffold New Features Using Your Existing Code Conventions
The best scaffolding follows your project's actual patterns — not framework defaults. Point Claude at your existing code before asking it to build anything new, and it'll match your conventions automatically.
claude "Read the existing PostsController, PostService, PostRepository, and their tests. Now scaffold a complete Comments feature following exactly the same patterns — controller with the same response format, service layer, repository, migrations, and Pest tests structured identically to the Post tests."
Claude picks up on things you didn't think to document: the specific HTTP status codes you return, whether you use DTOs or raw arrays, the way you name test datasets, and whether you favour method injection or constructor injection.
This works across the stack. For a Next.js project:
claude "Read the existing /app/products/ route group — page.tsx, loading.tsx, error.tsx, and the useProducts hook. Scaffold an identical /app/orders/ route group for orders data. Use the same fetch patterns, skeleton loaders, and error boundaries."
The key is giving Claude enough existing context before you ask it to generate:
claude "Before you write anything, read these five files and summarise the patterns you see: naming, structure, error handling, and test style. Then scaffold the new NotificationsModule following those exact patterns."
The explicit summary step catches mismatches before they get written into code.
Claude generates better scaffolding when it reads first — always show it the existing work before asking for the new work.
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.