deslop

name	deslop
description	Review a diff for local code quality, AI-generated slop, and polish in application code, configuration, documentation, and agent artifacts.
disable-model-invocation	true

Check the requested target or current changes for AI-generated slop.

Target

Accept zero or one argument:

/skill:deslop [<file-path> | <commit-sha>]

Pass the argument exactly as supplied to branch-diff, or run branch-diff without one. Treat its output as the complete review target; if it fails, ask the user to clarify.

Process

1. Resolve the review scope according to Target. Do not add a scope preamble to the first finding.
2. Establish the intended behavior from the request, relevant callers, tests, types, schemas, and documentation. Do not infer requirements solely from the changed implementation.
3. Inspect the selected file or diff and enough surrounding context to understand it. For a changeset, include unrelated generated files, configuration, documentation, agent skills, or formatting churn not produced or required by the repository formatter.
4. Focus on local slop within the selected scope. For a changeset, prioritize issues introduced or exposed by the change. Findings may cover concrete defects or preferences that would better match explicit user preferences, repository conventions, or the surrounding code. Judge the code under review, not whether it is committed or tracked. The only version-control finding allowed is incorrect .gitignore coverage.
5. Present exactly one finding at a time using Output format. Then wait for the user to choose a fix, ignore it, or give other instructions.
6. Interpret 1 or 2 as approval of the corresponding fix and I (case-insensitive) as ignore. If the user approves a fix or gives replacement instructions, make only that approved change and validate it before continuing.
7. After handling the user’s response, continue with the next finding using the same one-at-a-time process. If no material findings remain, use the exact no-findings output rather than inventing one.

Output format

Use this exact structure for every finding, replacing only the placeholders and omitting fix 2 when there is only one viable fix:

## {finding number}. {short finding title}

Location: {comma-separated file paths with line or line-range references}

{focused explanation of the defect and its consequence, with concise evidence and optional fenced code or diff blocks}

Fixes:

1. {smallest viable correction}
2. {alternative correction}

Fix (1), fix (2), (i)gnore, or tell what to do.

When there is one fix, the final line must instead be:

Fix (1), (i)gnore, or tell what to do.

Use this exact output when no material findings remain:

Right. Nothing else worth touching.

Formatting rules:

• Number findings consecutively from 1 for the review session.
• Format the title as a level-three Markdown heading so it renders bold and visually distinct. Keep it factual and specific; do not add a severity label.
• Use the field names Location and Fixes exactly as shown. Format labels in bold.
• Use repository-relative paths and precise line references. Join line ranges with an hyphen, for example src/file.ts:10-14.
• Keep the explanation focused on one issue. State the observed behavior, evidence, and practical consequence; do not pad it with a review summary or generic praise.
• Do not use second-person pronouns or attribute the code, decisions, or defects to the user. Refer to the code, change, implementation, or named symbols instead.
• Offer one or two numbered fixes only, with the preferred and smallest viable fix first.
• Do not add headings, preambles, conclusions, or choice text outside the template.

Focus areas

The review target may be application code, configuration, documentation, agent skills, CI definitions, or other repository artifacts. Load detailed checklists only for categories the changes touch.

Always apply

• Unrequested scope expansion: Unrelated refactors, speculative features, extra exports, new configuration, generated-file churn, unexplained lockfile changes, and formatting changes not produced or required by the repository formatter.
• Invented assumptions: Fabricated API fields, environment variables, routes, file formats, error shapes, library behavior, config keys, or documented steps unsupported by repository evidence.
• Repository inconsistency: Misleading names, formatting, or implementation patterns that conflict with explicit user preferences or nearby established conventions.

Category checklists

Load only the references needed for the changes under review:

• Code quality — comments, structure, dead code, completeness, clarity: read code-quality.
• JavaScript and TypeScript — types, async, Node.js, framework patterns: read javascript.
• Frontend and web — HTML, CSS, client JS, accessibility, obsolete patterns: read frontend. For HTML, CSS, or client-side JavaScript changes, also read the modern web guidance index. For React components, Next.js pages, or client rendering changes, also read the React best practices index. Load only the specific linked guides and rules relevant to the change.
• Backend logic — backend changes: read backend. For React Server Components, Server Actions, or Next.js route handlers, also read the React best practices index, then load only the specific linked rules relevant to the change.
• Security — unsafe interpolation, secrets, path handling: read security.
• Tests — hollow or meaningless tests: read tests.
• Dependencies — duplicate deps or unnecessary packages: read dependencies.
• Configuration and documentation — config, docs, or tooling without application code: read nocode.
• Agent skills and prompts — skill or prompt changes: read agent-skills.

When a changeset spans categories, load each relevant reference.

Guardrails

• Do not report uncommitted or untracked files as slop. Review the code on disk or in the diff, not git working-tree status. The only version-control finding allowed is incorrect .gitignore coverage: files that should be ignored but are not, or should be tracked but are wrongly ignored.
• Each finding needs explicit user approval or instructions before editing.
• Keep behavior unchanged unless fixing a clear bug.
• Prefer minimal, focused edits over broad rewrites.
• Do not recommend changes to public contracts, module responsibilities, ownership, data flow, or system architecture.
• Local conventions, explicit user preferences, correctness, and clarity override blanket style rules. Do not propose churn merely to satisfy a generic guideline.
• Do not abstract incidental similarity. Consolidate repetition in the target only when it clearly represents one concept or calculation.
• If you remove something, verify it’s truly unused first.
• Security findings: reference secret type and location only; never copy secret values.
• Do not flag intentional platform conventions or documented project conventions — unless the implementation adds risk beyond the convention.