anti-duplication

<objective>
The anti-duplication skill enforces the DRY (Don't Repeat Yourself) principle by proactively searching the codebase for existing patterns before writing new code. This prevents code duplication, reduces maintenance burden, and promotes code reuse.

Code duplication creates maintenance nightmares:
- Bug fixes must be applied in multiple places
- Features evolve inconsistently across duplicates
- Refactoring becomes exponentially harder
- Codebase grows unnecessarily large
- Onboarding takes longer (more code to learn)

This skill transforms "implement X" requests into a two-phase workflow:
1. **Search phase**: Find existing similar implementations (endpoints, components, services, models)
2. **Reuse or justify**: Either reuse/extend existing code OR justify why new implementation is necessary

The result: Codebases stay DRY, maintainable, and consistent.
</objective>

<quick_start>
<trigger_pattern>
When user says "create", "implement", "add", or "build" new functionality, **IMMEDIATELY** search for existing similar code before writing anything new.

**Trigger phrases**:
- "Create a new API endpoint for..."
- "Implement a component that..."
- "Add a service to handle..."
- "Build a model for..."
- "Write a function that..."
</trigger_pattern>

<basic_workflow>
**Step 1**: Extract search keywords from request
- User: "Create an API endpoint to fetch user profile"
- Keywords: "API endpoint", "fetch", "user", "profile", "GET"

**Step 2**: Search codebase for similar patterns

**PRIMARY: Semantic search (mgrep)**
- mgrep for: "API endpoints that fetch user data", "profile retrieval handlers"
- Finds similar implementations by meaning, not exact text

**SECONDARY: Literal search (Grep/Glob)**
- Grep for: "router.get", "app.get", "/api/user", "profile"
- Glob for: "**/*user*.ts", "**/*profile*.ts", "**/routes/**"

**Step 3**: Analyze findings
- Found 3 similar endpoints: GET /api/user/:id, GET /api/user/settings, GET /api/admin/users
- All use same auth middleware, validation pattern, error handling

**Step 4**: Present reuse options
- **Option A**: Extend existing GET /api/user/:id to include profile data
- **Option B**: Create new endpoint using same patterns as existing user endpoints
- **Option C**: Justify why completely new approach is needed

**Step 5**: Implement chosen option (with existing patterns as template)
</basic_workflow>

<immediate_value>
**Before anti-duplication skill**:
User: "Create an API endpoint to update user email"
Claude: *Writes new endpoint from scratch with different auth, validation, error handling*
Result: 5th variation of similar endpoint, inconsistent patterns

**After anti-duplication skill**:
User: "Create an API endpoint to update user email"
Claude: *Searches codebase, finds 4 existing user endpoints with consistent patterns*
Claude: "Found 4 similar user endpoints. They all use: authMiddleware, validateUserInput, standardErrorHandler. I'll create the new endpoint following this established pattern."
Result: Consistent implementation, reused middleware, maintainable code
</immediate_value>
</quick_start>

<workflow>
<step number="1">
**Parse the implementation request**

Extract key information:
- **Type**: What are they building? (endpoint, component, service, model, function, utility)
- **Domain**: What business domain? (user, product, order, payment, auth)
- **Operation**: What action? (create, read, update, delete, fetch, validate, transform)
- **Technology**: What stack? (React, Express, TypeScript, SQL, GraphQL)

Example parsing:
```
Request: "Create a React component to display product details"

Parsed:
- Type: React component
- Domain: Product
- Operation: Display/render
- Technology: React, TypeScript (likely)
```
</step>

<step number="2">
**Generate search strategies**

Create multiple search approaches to maximize coverage:

**PRIMARY: Semantic search (mgrep)**
Use mgrep FIRST for pattern discovery - finds similar code by meaning:
- "components that display product information"
- "services that handle email sending"
- "validation logic for user input"
- "error handling patterns in API routes"

mgrep finds UserCard, ProductCard, ProfileView when searching for "display user details" even if names don't match.

**SECONDARY: Literal searches (when mgrep insufficient)**

**A. Keyword-based searches** (Grep):
- Core domain terms: "product", "Product", "PRODUCT"
- Operation terms: "display", "render", "show", "view"
- Technology patterns: "React.FC", "function Component", "const.*=.*=>"

**B. File pattern searches** (Glob):
- Domain files: "**/*product*.tsx", "**/*Product*.tsx"
- Location patterns: "**/components/**/*Detail*.tsx", "**/components/**/Product*"
- Type-specific: "**/models/Product*", "**/services/product*"

**C. Structural searches** (Grep with regex):
- Class definitions: "class.*Product"
- Function exports: "export (function|const).*product"
- API patterns: "router\.(get|post|put|delete).*product"

See [references/search-strategies.md](references/search-strategies.md) for detailed patterns.
</step>

<step number="3">
**Execute searches in parallel**

Run multiple searches concurrently for speed:

**Phase 1: Semantic search (mgrep)**
```
mgrep "components that display product details"
mgrep "detail card patterns for entities"
```
Reviews results - if sufficient matches found, skip to Step 4.

**Phase 2: Literal searches (if needed)**
1. Grep: "product" in **/*.tsx (find all product-related components)
2. Grep: "ProductDetail" (find similar detail components)
3. Glob: "**/components/**/Product*.tsx" (find product component files)
4. Grep: "interface.*Product" (find product type definitions)
5. Grep: "display.*product.*props" (find rendering logic)

All searches run in parallel (see parallel-execution-optimizer skill).

**Time**: ~5-10 seconds for comprehensive search across large codebase.
</step>

<step number="4">
**Analyze search results**

Categorize findings:

**Exact matches**: Nearly identical implementations
- Exampl