techdebt

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:

# 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