| name | dry |
| description | Use this skill to find and eliminate duplication across your codebase — UI components, database schema, and workflow logic. Also use when the codebase feels bloated, features take longer to build, changes break in unexpected places, or after significant AI-assisted development. Covers code deduplication, component reuse, database normalization, and modular architecture. |
Don't Repeat Yourself
Find and eliminate duplication across your codebase. Every duplicate is a future bug — when you fix something in one place but forget the copy, users hit the unfixed version.
This skill audits and refactors. For building features, use build. For general performance optimization, use optimize. For database schema design from scratch, use database. For UI component selection, use ui-patterns.
Two Modes
| Mode | When | Scope | Time |
|---|
| Quick scan | After building a feature, or on request | Recent changes vs. existing codebase | 2-5 minutes |
| Deep audit | Codebase feels bloated, periodic cleanup | Entire codebase, all three domains | 15-30 minutes |
Choose quick scan after implementing features, adding new pages, or building new API endpoints. Choose deep audit when the codebase has grown through many rounds of AI-assisted iteration, or quarterly as hygiene.
Quick Scan Workflow
Run this after building or modifying a feature.
Quick DRY scan:
- [ ] Identify what was just built or changed
- [ ] Search for similar patterns in existing codebase
- [ ] Flag any duplication with specific file locations
- [ ] Refactor: extract shared code, reuse existing components
- [ ] Verify nothing broke after refactoring
Process
- Identify the change — What files were just created or modified?
- Search for siblings — For each new component, function, or query: does something similar already exist?
- Decide: reuse or extract — If a near-duplicate exists, reuse it. If two things are now similar, extract a shared version.
- Refactor — Make the change, run build and tests.
What to Search For
- New component created → search for components with similar props, layout, or purpose
- New utility function → search for functions with similar signatures or logic
- New API endpoint → search for endpoints with similar query patterns or response shapes
- New database query → search for queries hitting the same tables with similar conditions
Deep Audit Workflow
Run this for comprehensive deduplication across the full codebase.
Deep DRY audit:
- [ ] Audit UI components for duplication
- [ ] Audit database schema for normalization issues
- [ ] Audit workflow logic for duplicate functions and patterns
- [ ] Generate findings with specific refactoring actions
- [ ] Apply fixes domain by domain, testing after each
See AUDIT-CHECKLIST.md for detailed search patterns and refactoring recipes per domain.
Domain 1: UI Components
What to Find
- Near-duplicate components — Two card components, two modal wrappers, two form layouts with slight differences
- Repeated inline styles — Same padding, colors, or layout CSS copied across components instead of using shared tokens or classes
- Same-purpose components —
UserList and MemberList that do essentially the same thing with different prop names
- Reimplemented patterns — Custom dropdown when the component library already has one
How to Fix
- Identical components → Delete one, update imports to point to the survivor
- Near-duplicates → Extract a shared component with props for the differences
- Repeated styles → Extract into shared CSS classes, design tokens, or a utility class
- Reimplemented patterns → Replace with the component library version
AI-Tool-Specific Patterns
| Tool | Common Duplication | Why |
|---|
| Lovable | Each prompt creates new Card/Button/Modal variants | Lovable doesn't reference existing components by default |
| Replit | Inline styles duplicated across pages | Fast iteration favors copy-paste |
| Cursor | Similar components in different feature folders | File-scoped context misses cross-feature reuse |
| Claude Code | Utility components recreated in new feature branches | Context window doesn't always include existing shared components |
Tell AI (for other tools):
Search my codebase for duplicate UI components:
- Find components with similar JSX structure or props
- Find repeated inline styles or CSS classes
- Find components that render the same kind of data differently
For each duplicate: show both versions side-by-side and propose a single shared component.
Domain 2: Database Schema
What to Find
- Denormalized data — User's email stored in both
users table and orders table instead of joining
- Missing foreign keys — IDs stored as plain integers/strings without proper references
- Repeated column groups —
created_at, updated_at, created_by defined inconsistently across tables
- Enum values in columns — Status strings like
'active', 'inactive' repeated instead of using a lookup table
- Duplicate lookup data — Category names stored as strings in every row instead of referencing a categories table
How to Fix
- Denormalized data → Remove the duplicate column, add a JOIN where needed
- Missing foreign keys → Add proper FK constraints with ON DELETE behavior
- Repeated column groups → Standardize naming and types across all tables
- String enums → Create a lookup table or use a database enum type (for values that won't change)
- Duplicate lookup data → Extract into a reference table, replace with foreign key
Red Flags in AI-Generated Schemas
AI tools often create self-contained tables per feature. Watch for:
- A
projects table with owner_name and owner_email instead of owner_id referencing users
- An
invoices table with customer_name, customer_email, customer_address instead of customer_id
- Multiple tables with their own
status VARCHAR column using the same string values
Tell AI (for other tools):
Audit my database schema for normalization issues:
- Find columns that store data already available in another table
- Find ID columns without foreign key constraints
- Find string columns that should be lookup tables
- Find inconsistent column naming across tables
For each: explain the problem and write the migration to fix it.
Domain 3: Workflow Logic
What to Find
- Duplicate utility functions — Two
formatDate() functions in different files
- Repeated API patterns — Same fetch-try-catch-error-handle boilerplate across endpoints
- Copy-pasted validation — Email validation logic in signup, settings, and invite flows
- Duplicate business logic — Price calculation in checkout, invoice generation, and dashboard
- Repeated data transforms — Same array mapping/filtering logic in multiple components
How to Fix
- Duplicate utilities → Keep one, move to a shared
utils/ or lib/ directory, update all imports
- API boilerplate → Extract a shared API client or wrapper function
- Repeated validation → Create a shared validation module (e.g.,
lib/validators.ts)
- Business logic → Extract into a service or domain module (e.g.,
lib/pricing.ts)
- Data transforms → Extract into named functions near the data type they operate on
Search Strategy
Find duplicate logic:
1. Search for functions with identical or near-identical bodies
2. Search for repeated import patterns (same 3+ imports in multiple files)
3. Search for similar try/catch blocks around API calls
4. Search for the same regex or validation pattern in multiple files
5. Search for string literals used in more than 2 files (often config that should be a constant)
Tell AI (for other tools):
Audit my codebase for duplicate workflow logic:
- Find functions with similar names or identical logic in different files
- Find repeated error handling patterns
- Find validation logic that appears in more than one place
- Find business calculations done in more than one place
For each: show all locations and propose a single shared implementation.
What NOT to Deduplicate
Not all duplication is bad. Don't over-abstract.
| Leave It Alone | Why |
|---|
| Two functions that look similar but serve different business purposes | They'll diverge. Premature abstraction creates coupling. |
| Test setup code that repeats across test files | Test readability matters more than test DRYness. |
| Simple one-liners used twice | Extracting adds indirection without meaningful reuse. |
| Code that's similar today but will evolve differently | Shared abstractions should reflect stable, shared concepts. |
| Configuration that's the same across environments by coincidence | Config should be explicit per environment, not shared. |
Rule of three: If something appears in 3+ places, extract it. If it's only in 2 places, wait until the third occurrence to confirm it's a real pattern, not coincidence.
Common Mistakes
| Mistake | Fix |
|---|
Creating a utils.ts mega-file | Group by domain: lib/pricing.ts, lib/validation.ts, lib/formatting.ts |
| Abstracting before the pattern stabilizes | Wait for 3+ occurrences. Two similar things might diverge. |
| Breaking working code to "clean it up" | Run build and tests after every refactoring step |
| Over-parameterizing a shared component | If a component needs 10 props to handle all cases, it's doing too much |
| Deduplicating across feature boundaries prematurely | Features that share code today might need to diverge tomorrow |
Success Looks Like
After a DRY audit, you should see:
- Each UI component exists once with clear props for variation
- Database tables reference each other via foreign keys instead of duplicating data
- Shared logic lives in clearly named modules under
lib/ or utils/
- No function body is copy-pasted across files
- New features can reuse existing components and utilities instead of recreating them
Related Skills
- optimize — Performance and cleanup (speed, dependencies, dead code)
- database — Schema design, RLS, migrations, query patterns
- ui-patterns — Component selection, state matrix, page composition
- build — Feature development workflow and AI tool prompting
- debug — When deduplication breaks something
