Deslop Typescript

Deslop TypeScript

Use this skill after the code works and before commit, PR, or review handoff. The goal is to leave the smallest clear diff that improves readability, type integrity, and repo fit without turning the task into a refactor.

This skill is based on the slop-scan model: deterministic slop heuristics for JS/TS repos, plus a review workflow that focuses fixes on worthwhile, local cleanup.

Goals

• Remove obvious slop without widening scope.
• Prefer compile-time guarantees over runtime ceremony inside typed repo-owned code.
• Collapse unnecessary wrappers, pass-through helpers, and placeholder structure.
• Keep repo conventions, docs, and ownership boundaries intact.

When To Use

Use this skill when:

• the change is already functionally correct
• the repo is primarily JavaScript or TypeScript
• you want a final cleanup pass before commit or PR
• code feels AI-assisted, over-abstracted, or noisier than the surrounding repo

Do not use this skill when:

• the feature is still incomplete or behavior is still changing
• the task is mostly non-JS/TS code
• the user asked for a broad refactor rather than a narrow cleanup

Core Review Vectors

Review the changed area through these lenses:

1. Repo conformance
   • Follow repo AGENTS.md, nested AGENTS.md, design docs, and established local patterns.
   • Prefer the style already present in the touched area over generic cleanup instincts.
2. Type safety and source of truth
   • Preserve canonical types instead of re-declaring or widening them.
   • Remove unnecessary casts, redundant parsing, and boundary checks inside trusted typed code.
   • Keep validation at genuinely untrusted boundaries.
3. Simplicity
   • Remove wrappers, factories, and helpers that only rename or pass through values.
   • Inline trivial indirection when it improves readability locally.
4. Slop hotspots
   • Look for patterns slop-scan commonly flags: pass-through wrappers, return await noise, placeholder comments, duplicated helpers, fragmented files, weak catch blocks, and repeated setup boilerplate.

Context Bundle

Before editing, gather only the context that matters for the changed area:

• repo root AGENTS.md
• nearest nested AGENTS.md files for touched paths
• relevant design docs or architecture notes
• the changed files plus nearby callers, callees, and types
• project scripts or config for lint, typecheck, test, and slop-scan

If an active plan or execution doc exists for the work, read it before cleanup so you do not remove intentional structure.

Scope Selection

Default to the current changed files unless the user explicitly names a branch to deslop against.

For the default scope, inspect local changed JS/TS files from the working tree and index:

git diff --name-only --diff-filter=ACMR -- '*.js' '*.jsx' '*.ts' '*.tsx'
git diff --cached --name-only --diff-filter=ACMR -- '*.js' '*.jsx' '*.ts' '*.tsx'
git ls-files --others --exclude-standard -- '*.js' '*.jsx' '*.ts' '*.tsx'

If the user says to deslop against a branch, use the current checkout compared to that branch. Prefer a local ref when present, then fall back to origin/<branch>:

target_branch="<branch-from-user>"
target_ref="$target_branch"
git rev-parse --verify --quiet "$target_ref" >/dev/null || target_ref="origin/$target_branch"
merge_base="$(git merge-base HEAD "$target_ref")"
git diff --name-only --diff-filter=ACMR "$merge_base" HEAD -- '*.js' '*.jsx' '*.ts' '*.tsx'

Use that branch-diff file list to choose the changed area, nearby callers/callees, and any narrow slop-scan roots. If local working tree or indexed changes also exist, include them only when they are part of the requested deslop pass or when the user asks for all current changes.