$ recombobulate _
home / tips / point-at-an-existing-feature-and-say-build-another-one-like-this-for-instant-scaffolding
136

Point at an Existing Feature and Say "Build Another One Like This" for Instant Scaffolding

recombobulate @recombobulate · Mar 30, 2026 · Workflows
point-at-an-existing-feature-and-say-build-another-one-like-this-for-instant-scaffolding

Building a new feature that mirrors an existing one means creating the same set of files — model, migration, controller, routes, views, tests, factory — but with different names, relationships, and fields. Instead of copying and find-replacing, let Claude read the existing feature and scaffold the new one.

> read how the Users feature is built — the model, migration,
> controller, routes, views, form request, policy, and tests —
> then build the same thing for Products with name, price,
> description, and category_id fields

Claude reads every file in the existing feature, understands the patterns (how the controller structures its methods, how the views are laid out, how the tests are organized), and creates a complete set of new files that follow the exact same conventions — just for the new resource.

This works for any feature pattern:

> look at how the blog posts module is structured — admin CRUD,
> public listing, API endpoints, and tests — then build the same
> structure for a recipes module

> read the existing payment webhook handler for Stripe and build
> the same pattern for a PayPal webhook handler

> look at the user settings page (controller, Livewire component,
> blade view, tests) and create the same structure for a
> notification preferences page

Claude doesn't just copy — it adapts. The new feature gets:

  • Correct model relationships — if Users had hasMany posts, Products gets the right relationships for its context
  • Matching validation rules — tailored to the new resource's fields, not copied verbatim
  • Proper route namingproducts.index, products.store, etc., matching the existing convention
  • Updated tests — testing the new resource's specific fields and behaviors
  • Factory definitions — with realistic data for the new model's columns

This is especially powerful for teams with established patterns — the first feature sets the convention, and every subsequent one matches it perfectly without anyone having to remember all the pieces.

Your best features are templates for the next ones — point Claude at the pattern and let it replicate it perfectly.

via Claude Code

~/recombobulate $ tip --comments --count=0

Log in to leave a comment.

~/recombobulate $ tip --related --limit=3
0
Run Claude Code in GitHub Actions to Automatically Review Every Pull Request

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.

recombobulate @recombobulate · 1 day ago
0
Ask Claude to Build a Deployment Checklist from Your Actual Infrastructure

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.

recombobulate @recombobulate · 1 day ago
0
Ask Claude to Generate a README from Your Actual Codebase — Not a Template

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.

recombobulate @recombobulate · 1 day ago