---
name: techdebt
description: >-
  Review a code diff / branch / PR for technical debt — code duplication,
  unnecessary complexity / over-engineering, and redundant or dead code. Use
  whenever the user wants a tech-debt, cleanup, or refactor review, asks to check
  a branch or PR for duplication / complexity / dead code before opening a PR, or
  mentions "techdebt". Refactor-only: it reports issues and offers
  behavior-preserving fixes; it never changes behavior.
user-invocable: true
context: fork
allowed-tools:
  - Bash
  - Read
  - Grep
  - Glob
---

# Techdebt Cleanup Skill

Analyze changes on the current branch to identify and fix technical debt, code duplication, and unnecessary complexity.

## Instructions

### Step 1: Get Branch Changes

Find the merge-base (where this branch diverged from master) and compare against it:

```bash
# Find upstream (DataDog org repo)
UPSTREAM=$(git remote -v | grep -E 'DataDog/[^/]+(.git)?\s' | head -1 | awk '{print $1}')
if [ -z "$UPSTREAM" ]; then
  echo "No DataDog upstream found, using origin"
  UPSTREAM="origin"
fi

# Find the merge-base (commit where this branch diverged from master)
MERGE_BASE=$(git merge-base HEAD ${UPSTREAM}/master)
echo "Comparing changes introduced on this branch since diverging from master using base commit: $MERGE_BASE"

git diff $MERGE_BASE --stat
git diff $MERGE_BASE --name-status
```

If no changes exist, inform the user and stop.

If changes exist, read the diff and the full content of modified source files (not test files) to understand context.

### Step 2: Analyze for Issues

Look for:

**Code Duplication**
- Similar code blocks that should be extracted into shared functions
- Copy-pasted logic with minor variations

**Unnecessary Complexity**
- Over-engineered solutions (abstractions used only once)
- Excessive indirection or layers
- Backward compatibility shims that aren't needed

**Redundant Code**
- Dead code paths
- Overly defensive checks for impossible scenarios

### Step 3: Report and Fix

Present a concise summary of issues found with file:line references.

Then ask the user if they want you to fix the issues. When fixing:
- Make one logical change at a time
- Do NOT change behavior, only refactor
- Skip trivial or stylistic issues