agentleFS
Sign inStart free
RileyCorneliusRileyCornelius/Code-Skills/skills/code-simplifier/SKILL.md

code-simplifier

Skill0 starsChanged 7 months agoMITView on GitHub

Simplify recently changed code for clarity, consistency, and maintainability without changing behavior. Use when the user wants a cleanup, refactor, polish pass, or readability improvement on code that already works and should keep the same functionality.

59 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use tdd-rust, type-design-analyzer and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • FlorianBruniauxSkill

    tdd-rust

    Also in 3 projects that use this

  • PaulKinlanSkill

    type-design-analyzer

    Analyzes type design quality focusing on encapsulation, invariant expression, usefulness, and enforcement. Provides quantitative ratings (1-10) for each dimension.

    Also in 3 projects that use this

  • PaulKinlanSkill

    comment-analyzer

    Analyzes code comments for accuracy, completeness, and long-term maintainability. Identifies misleading comments, comment rot, and documentation gaps.

    Also in 4 projects that use this

  • ufodev-ioSkill

    security-guardian

    Comprehensive security layer for all interactions with Claude: audits code, dependencies, commands, configs, and AI-generated output for vulnerabilities. Protects against prompt injection, data leaks, unsafe advice, and social engineering. Works in Cursor, Claude Code, claude.ai, and API contexts. Use always as a background security protocol in any Claude-powered environment.

    Also in 3 projects that use this

  • SentrySkill

    find-bugs

    Find bugs, security vulnerabilities, and code quality issues in local branch changes. Use when asked to review changes, find bugs, security review, or audit code on the current branch.

    Also in 3 projects that use this

  • tossSkill

    pr-triage

    Classify and summarize a PR for efficient review

    Also in 3 projects that use this

  • +1 more from PaulKinlan

The file

Show its rules and text

We split this skill into the rules it gives an agent

22 rules. 0 are common, 21 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 54 edited versions we read keep these.

  • 21

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not intentionally change user-visible behavior, outputs, interfaces, or side effects.

    line 13
  2. Distinctive:

    Treat behavioral safety as a requirement, not a hope.

    line 14
  3. Distinctive:

    Before finishing, verify preservation with the strongest available signal:

    line 15
  4. Distinctive:

    Run existing targeted tests when they exist.

    line 16
  5. Distinctive:

    Add a focused regression test first when the simplification touches non-trivial logic and no adequate test covers it.

    line 17
  6. Distinctive:

    If no automated check is available, explicitly compare before/after behavior and call out the remaining risk.

    line 18
  7. Distinctive:

    Read the repository's documented standards before simplifying code.

    line 21
  8. Distinctive:

    Use CLAUDE.md, AGENTS.md, README.md, lint config, formatter config, and nearby examples as possible sources.

    line 22
  9. Distinctive:

    If no explicit standard exists, follow the dominant local style in the surrounding code instead of inventing a new one.

    line 23
  10. Distinctive:

    Remove comments that only restate obvious code.

    line 30
  11. Very specific:

    Avoid nested ternary operators when a clearer if/else chain or switch is better.

    line 31
  12. Distinctive:

    Do not oversimplify in ways that reduce clarity or maintainability.

    line 35
  13. Distinctive:

    Do not introduce cleverness that is harder to debug or extend.

    line 36
  14. Distinctive:

    Do not collapse too many concerns into a single function or component.

    line 37
  15. Distinctive:

    Do not remove abstractions that are still earning their keep.

    line 38
  16. Distinctive:

    Do not optimize for fewer lines at the expense of readability.

    line 39
  17. Distinctive:

    Default to code that was recently modified, unless the user explicitly broadens the request.

    line 42
  18. Distinctive:

    If none of these produce a clear scope, state the ambiguity and choose the smallest reasonable scope instead of roaming through the …

    line 48
  19. Distinctive:

    Read nearby code and repo standards so the simplification matches local patterns.

    line 53
  20. Distinctive:

    Look for opportunities to reduce complexity, duplication, and incidental noise.

    line 54
  21. Distinctive:

    Verify that behavior remains unchanged using tests or the strongest available check.

    line 56
  22. Distinctive:

    Document only the meaningful changes or residual risks that affect understanding.

    line 57

“Common” is measured: kept by at least 6 in 10 of the 54 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Code Simplifier

Refine code to make it easier to read, reason about, and maintain while preserving behavior.

Operating Rules

  1. Preserve functionality
    • Do not intentionally change user-visible behavior, outputs, interfaces, or side effects.
    • Treat behavioral safety as a requirement, not a hope.
    • Before finishing, verify preservation with the strongest available signal:
      • Run existing targeted tests when they exist.
      • Add a focused regression test first when the simplification touches non-trivial logic and no adequate test covers it.
      • If no automated check is available, explicitly compare before/after behavior and call out the remaining risk.
  2. Follow project standards
    • Read the repository's documented standards before simplifying code.
    • Use CLAUDE.md, AGENTS.md, README.md, lint config, formatter config, and nearby examples as possible sources.
    • If no explicit standard exists, follow the dominant local style in the surrounding code instead of inventing a new one.
  3. Enhance clarity
    • Reduce unnecessary complexity and nesting.
    • Eliminate redundant code and unnecessary abstractions.
    • Improve readability through clear variable and function names.
    • Consolidate related logic when it improves comprehension.
    • Remove comments that only restate obvious code.
    • Avoid nested ternary operators when a clearer if/else chain or switch is better.
    • Choose clarity over brevity. Explicit code is often better than dense one-liners.
  4. Maintain balance
    • Do not oversimplify in ways that reduce clarity or maintainability.
    • Do not introduce cleverness that is harder to debug or extend.
    • Do not collapse too many concerns into a single function or component.
    • Do not remove abstractions that are still earning their keep.
    • Do not optimize for fewer lines at the expense of readability.
  5. Control scope
    • Default to code that was recently modified, unless the user explicitly broadens the request.
    • Determine scope in this order:
      • User-specified files, symbols, or directories.
      • Staged or unstaged changes in git.
      • The current branch diff against its base when that is the clearest definition of "recently modified."
      • Files touched in the current session, if available from local context.
    • If none of these produce a clear scope, state the ambiguity and choose the smallest reasonable scope instead of roaming through the codebase.

Workflow

  1. Identify the target scope using the scope rules above.
  2. Read nearby code and repo standards so the simplification matches local patterns.
  3. Look for opportunities to reduce complexity, duplication, and incidental noise.
  4. Make the smallest changes that materially improve readability and maintainability.
  5. Verify that behavior remains unchanged using tests or the strongest available check.
  6. Document only the meaningful changes or residual risks that affect understanding.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free