dry

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

1. Identify the change — What files were just created or modified?
2. Search for siblings — For each new component, function, or query: does something similar already exist?
3. Decide: reuse or extract — If a near-duplicate exists, reuse it. If two things are now similar, extract a shared version.
4. 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

1. Identical components → Delete one, update imports to point to the survivor
2. Near-duplicates → Extract a shared component with props for the differences
3. Repeated styles → Extract into shared CSS classes, design tokens, or a utility class
4. 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

1. Denormalized data → Remove the duplicate column, add a JOIN where needed
2. Missing foreign keys → Add proper FK constraints with ON DELETE behavior
3. Repeated column groups → Standardize naming and types across all tables
4. String enums → Create a lookup table or use a database enum type (for values that won't change)
5. 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

1. Duplicate utilities → Keep one, move to a shared utils/ or lib/ directory, update all imports
2. API boilerplate → Extract a shared API client or wrapper function
3. Repeated validation → Create a shared validation module (e.g., lib/validators.ts)
4. Business logic → Extract into a service or domain module (e.g., lib/pricing.ts)
5. 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