Name a Design Pattern and Let Claude Apply It to Your Actual Code
You know the code smells but aren't sure which pattern fixes it. Or you know the pattern but don't want to spend an hour wiring it up. Name the pattern and Claude applies it to your code.
"Apply the Repository pattern to the User model — extract all
database queries from the controllers into a UserRepository"
Claude reads your controllers, finds every direct Eloquent call, creates the repository class with proper methods, and updates all the controllers to use it — including dependency injection and any interface you'd need for testing.
This works for any design pattern:
# Strategy pattern
"The discount calculation has a growing if/else chain.
Apply the Strategy pattern — one class per discount type."
# Observer pattern
"When an order status changes, we need to send emails, update
inventory, and log the event. Apply the Observer pattern."
# Decorator pattern
"The logger has too many optional features — file output,
Slack notifications, structured formatting. Apply the
Decorator pattern so they compose cleanly."
# Factory pattern
"We create notifications in 12 different places with similar
but different setup. Apply the Factory pattern."
# Specification pattern
"The product filtering logic is duplicated across controllers
and API endpoints. Apply the Specification pattern."
You can also describe the problem and let Claude pick the pattern:
"This switch statement keeps growing every time we add a new
payment method. What design pattern would fix this? Apply it."
Claude doesn't just implement the pattern — it adapts it to your framework. A Repository in Laravel uses Eloquent. A Strategy in React uses hooks or context. An Observer in Node uses EventEmitter.
Design patterns solve real problems — but only if you apply them. Name the pattern, point at the code, and let Claude do the refactoring.
via Claude Code
Log in to leave a comment.
Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.
Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.
Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.