Skip to main content

simplify

Simplify code while preserving behavior when asked for cleanup, refactoring, or Simplify. Not an automatic post-edit pass or prose cleanup.

Source facts

Repository
davesnx/setup
Last source activity
September 14, 2026 at 17:36
Detected SKILL.md language
English
Stars
11
Forks
1

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
18 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
simplify
description
Simplify code while preserving behavior when asked for cleanup, refactoring, or Simplify. Not an automatic post-edit pass or prose cleanup.
# Simplify Review the diff and remove changes that are slop: unnecessary, non-idiomatic, or inconsistent additions that do not contribute to the intended feature or fix. Reduce the code and concepts the project must maintain while preserving the contract. Keep the smallest change that accomplishes the goal, and match the local conventions of each touched file. For a review-only request, report findings without edits. For prose cleanup, use Unslop. When another workflow owns the task, preserve its edit boundary. Load `code-standards` when a cleanup decision needs its guidance on boundaries, persistence, error handling, or state models, not for every edit in those areas. ## 1. Bound the scope Use named files or a fixed point when the user supplies them. Otherwise combine staged and unstaged changed files. If the worktree is clean, compare the current branch with the merge base of the repository's base branch. Exclude unrelated files. Stop and report when the scope contains no code. Complete when the exact file list and comparison point are known. ## 2. Establish the baseline Read every selected file, its relevant callers and tests, and nearby project conventions. For each changed hunk, determine the intended behavior change. Identify public contracts and current observable behavior. Search for an existing canonical helper before proposing reuse or extraction. Apply the lenses below directly for a bounded change. Use independent read-only reviewers when separate parts or risks justify parallel work, not because a file-count threshold was crossed. Give each reviewer a distinct question, exact scope, and required `file:line` evidence. Complete when each candidate change has a known behavior to preserve and an identified owner. ## 3. Find removable complexity Prefer deletion or existing code, then language or platform features, established dependencies, and direct local code. Add an abstraction or dependency only when a demonstrated need outweighs its maintenance cost. Keep one-use behavior direct. Split code by responsibility, not file size. Use these lenses: ### Reuse - Duplicated logic within or across changed files. - Copy-pasted behavior that should use one existing owner. - New helpers that duplicate a canonical path. - Abstractions that can be replaced by a direct existing path. ### Structure and quality - Unused imports, values, parameters, dead code, unreachable branches, and stale compatibility paths. - Pass-through wrappers, shallow modules, and abstractions with one use. - Configuration, extension points, and optional behavior that no requirement or caller uses. - Deep nesting that a guard clause, direct flow, or better state model removes. - Defensive checks, fallbacks, retries, or catches that are abnormal on a trusted path and hide defects. - `any`, casts, optional values, or ignored errors used to bypass a type or invariant. ### Clarity - Comments that restate code or no longer match it. - Vague names, several names for one concept, and names that expose machinery instead of purpose. - Intermediate variables or state that obscure the flow rather than explain it. - Dense expressions that save lines but make behavior harder to see. ### Efficiency - Repeated computation, lookup, allocation, copying, or I/O with material cost. - Accidental quadratic work when a direct linear path is clear. - Missed short-circuiting or unnecessary sequential work. - Caches, concurrency, or batching added without evidence that they solve a real constraint. Weight the review toward any user-supplied focus, such as errors, duplication, naming, memory, or performance. Preserve validation, diagnostics, security, accessibility, compatibility, and intentional behavior. A shorter implementation that drops these is not a simplification. Report a correctness issue separately when it requires a behavior change. Validate each candidate against actual callers and repository conventions. Merge overlaps and rank significant duplication, structural confusion, unsafe type escapes, or material inefficiency as high; clear local readability, naming, nesting, dead-code, or consistency gains as medium; and optional style as low. Discard speculative abstractions, micro-optimizations, and changes that only move complexity elsewhere. Complete when every retained candidate names the code to remove or replace, the reason it is simpler, and the behavior it preserves. ## 4. Apply focused edits Edit by default. Before editing, give one compact summary grouped by file. Apply high and medium behavior-preserving reductions. Apply low findings only when they are local and reduce code or cognitive load. Align each edit with local style: naming, typing, error strategy, and comment density. Do not add dependencies. Keep edits inside the selected scope unless the shared owner of a root cause lies outside it. Report an outside root cause and cross the boundary only after the user expands the scope. Rename public interfaces or change behavior only when the user authorizes that change. If the pass finds a bug that requires a behavior change, report it instead of hiding the fix inside cleanup unless the user also asked to fix bugs. Complete when the selected complexity is removed without changing required behavior or public contracts. ## 5. Verify and report After the final edit, run the repository's formatters, linters, and tests for the preserved behavior, and introduce no new warnings. Inspect the diff for unrelated changes and confirm it still satisfies AGENTS.md and other repository policies. Report in one to three sentences: what was removed or reused, what stayed unchanged, and which checks passed or could not run. No bullet points, no emojis, no extended explanation. Mention rejected or deferred candidates only when they explain an important tradeoff. Example: > Removed redundant input checks and log-and-rethrow blocks added in this > branch, and inlined single-use helpers to match existing style. No functional > behavior changes beyond the intended diff; all edits were confined to the > branch's modified hunks. Complete when checks pass and the summary contains only verified claims.
View on GitHub