Code Smell Detector

You are a code quality expert. Scan the codebase for code smells and produce a prioritized list of improvements.

Step 1: Find Long Functions

# Find files with functions longer than 50 lines (likely need splitting)
# List the largest source files first
find . -name "*.ts" -o -name "*.tsx" -o -name "*.js" -o -name "*.jsx" -o -name "*.py" | grep -v node_modules | grep -v .next | xargs wc -l 2>/dev/null | sort -rn | head -20

Read the top 10 largest files. For each, identify:

• Functions longer than 50 lines — these should be split into focused, single-purpose functions
• Functions with more than 4 parameters — use a parameter object instead
• Functions with more than 3 levels of nesting — flatten with early returns or extract helper functions

Step 2: Find Code Duplication

# Look for similar function signatures that might be duplicated
grep -rn --include="*.ts" --include="*.tsx" --include="*.js" "export function\|export const.*=.*=>" . --exclude-dir=node_modules --exclude-dir=.next | sort -t: -k3 | head -40

# Find similar import patterns (indicates shared utilities needed)
grep -rn --include="*.ts" --include="*.tsx" "^import" . --exclude-dir=node_modules --exclude-dir=.next | awk -F'from' '{print $2}' | sort | uniq -c | sort -rn | head -20

Read files that look like they might contain duplicate logic. Common duplication spots:

• Validation logic repeated across multiple API routes
• Error handling patterns copy-pasted between files
• Data transformation functions that do the same thing with slight variations
• Utility functions re-implemented in multiple places

For each duplication, suggest extracting to a shared utility.

Step 3: Find Dead Code

# Find exported functions — check if they're imported anywhere
grep -rn --include="*.ts" --include="*.tsx" "export function\|export const\|export class\|export interface\|export type" . --exclude-dir=node_modules --exclude-dir=.next | head -40

# Find unused variables/imports (TypeScript)
npx tsc --noEmit --noUnusedLocals --noUnusedParameters 2>&1 | grep "declared but" | head -20

# Find files that aren't imported by anything
find . -name "*.ts" -o -name "*.tsx" | grep -v node_modules | grep -v .next | grep -v "page\.\|layout\.\|route\." | while read f; do
  base=$(basename "$f" | sed 's/\.[^.]*$//')
  count=$(grep -rn --include="*.ts" --include="*.tsx" "$base" . --exclude-dir=node_modules --exclude-dir=.next | grep -v "$f" | wc -l)
  if [ "$count" -eq 0 ]; then echo "POSSIBLY UNUSED: $f"; fi
done 2>/dev/null | head -15

For each potentially dead code finding, verify by reading the file and checking if it's used via dynamic imports, config references, or framework conventions (like Next.js page files).

Step 4: Find Complexity Issues

Read source files and look for:

Deeply Nested Conditionals

• More than 3 levels of if/else nesting
• Fix: use early returns, guard clauses, or extract helper functions

God Objects/Files

• Single files that handle too many responsibilities
• Fix: split into focused modules with single responsibility

Boolean Parameters

• Functions that take boolean flags to control behavior: processOrder(order, true, false, true)
• Fix: use named options object: processOrder(order, { validate: true, notify: false, async: true })

Magic Numbers & Strings

• Hardcoded values like if (retries > 3) or role === "admin"
• Fix: extract to named constants: const MAX_RETRIES = 3

Inappropriate Intimacy

• Modules reaching deep into other modules' internal structures
• Fix: expose proper interfaces/APIs

Step 5: Check Naming Quality

Read through the main source files and flag:

• Single-letter variables outside of loop iterators: const d = getData() should be const dashboardData = getData()
• Misleading names: function called getUser that also modifies the database
• Inconsistent naming: mixing camelCase and snake_case in the same codebase
• Vague names: data, result, temp, info, handler, manager, utils
• Boolean variables not starting with is, has, should, can

Step 6: Output the Report

## Code Smell Report

**Files Scanned**: [count]
**Total Smells Found**: [count]

---

### High Priority (fix these first)

1. **[file:line]** — [Smell type]: [Title]
   **Why it matters**: [Impact on maintainability, readability, or bug risk]
   **Fix**:
   ```suggestion
   // Show the improved code

Medium Priority

1. [file:line] — [Smell type]: [Title] Suggestion: [How to improve]

Low Priority

1. [file:line] — [Smell type]: [Title] Note: [Brief suggestion]

Dead Code to Remove

• [file] — [What's unused and can be safely deleted]

Summary

Smell Type	Count
Long Functions	...
Duplication	...
Dead Code	...
Complex Nesting	...
Poor Naming	...
Magic Numbers	...

Top 3 refactoring priorities:

1. [Most impactful]
2. [Second]
3. [Third]

## Rules

- Focus on smells that impact maintainability and bug risk, not personal style preferences.
- For every smell, explain WHY it's a problem, not just WHAT it is.
- Show the fix for high-priority items.
- Verify dead code findings — framework convention files (pages, routes, layouts) are NOT dead code.
- Group related smells together if they should be fixed as a single refactor.

## Common Pitfalls

- Treating this skill as a one-shot solution — most workflows need iteration and verification
- Skipping the verification steps — you don't know it worked until you measure
- Applying this skill without understanding the underlying problem — read the related docs first


## When NOT to Use This Skill

- When a simpler manual approach would take less than 10 minutes
- On critical production systems without testing in staging first
- When you don't have permission or authorization to make these changes


## How to Verify It Worked

- Run the verification steps documented above
- Compare the output against your expected baseline
- Check logs for any warnings or errors — silent failures are the worst kind


## Production Considerations

- Test in staging before deploying to production
- Have a rollback plan — every change should be reversible
- Monitor the affected systems for at least 24 hours after the change