agentleFS
1024XEngineer1024XEngineer/bytemind/.agents/skills/code-simplifier/SKILL.md

code-simplifier

Skill43 starsChanged 6 months agoMITView on GitHub

simplifies and refines code for clarity, consistency, and maintainability while preserving exact functionality. use when chatgpt needs to review, clean up, or simplify recently modified code, align code with project conventions, reduce unnecessary complexity, improve readability, or make implementation details more explicit without changing behavior.

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

24 rules. 0 are common, 20 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 54 edited versions we read keep these.

  • 20

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not change features, outputs, side effects, or observable behavior.

    line 12
  2. Distinctive:

    Do not broaden scope unless the user explicitly asks for a wider review.

    line 14
  3. Distinctive:

    Prefer refining the code that was just written or edited.

    line 18
  4. Distinctive:

    Avoid unrelated cleanup in untouched areas.

    line 19
  5. Distinctive:

    Prefer explicit, readable code over compact code.

    line 21
  6. Distinctive:

    Avoid clever one-liners when a straightforward structure is easier to read.

    line 24
  7. Very specific:

    Avoid nested ternary operators.

    line 25
  8. Distinctive:

    When the repository or provided guidance includes project standards such as CLAUDE.md, follow them closely.

    line 29
  9. Distinctive:

    Use ES modules with proper import sorting and explicit extensions where required.

    line 33
  10. Very specific:

    Prefer the function keyword over arrow functions when that is the project standard.

    line 34
  11. Distinctive:

    Add explicit return type annotations for top-level functions when the project expects them.

    line 35
  12. Very specific:

    Follow established React component patterns with explicit Props types.

    line 36
  13. Very specific:

    Use the repository’s preferred error-handling patterns and avoid introducing unnecessary try/catch.

    line 37
  14. Distinctive:

    If no project standard is available, preserve the local style of the surrounding code while still simplifying it.

    line 40
  15. Distinctive:

    Look for opportunities to:

    line 44
  16. Distinctive:

    remove comments that only restate obvious code behavior

    line 51
  17. Distinctive:

    keep helpful abstractions that improve organization

    line 53
  18. Distinctive:

    Do not simplify in ways that:

    line 55
  19. Distinctive:

    remove abstractions that help structure the codebase

    line 61
  20. Distinctive:

    Check for project-specific conventions from repository guidance and nearby code.

    line 68
  21. Distinctive:

    keep edits scoped and intentional

    line 78
  22. Distinctive:

    avoid noisy reformatting unrelated to the simplification

    line 80
  23. Distinctive:

    prefer a few high-confidence improvements over broad cosmetic churn

    line 81
  24. Distinctive:

    When summarizing your work:

    line 83

“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

Refine recently modified code for clarity, consistency, and maintainability while preserving exact functionality.

Core behavior

Preserve behavior exactly.

  • Do not change features, outputs, side effects, or observable behavior.
  • Change how the code is written, not what it does.
  • Do not broaden scope unless the user explicitly asks for a wider review.

Focus on code that was recently modified or touched in the current session.

  • Prefer refining the code that was just written or edited.
  • Avoid unrelated cleanup in untouched areas.

Prefer explicit, readable code over compact code.

  • Choose clarity over brevity.
  • Avoid clever one-liners when a straightforward structure is easier to read.
  • Avoid nested ternary operators. Use if/else chains or switch statements for multiple conditions.

Apply project conventions

When the repository or provided guidance includes project standards such as CLAUDE.md, follow them closely.

Common conventions to apply when present:

  • Use ES modules with proper import sorting and explicit extensions where required.
  • Prefer the function keyword over arrow functions when that is the project standard.
  • Add explicit return type annotations for top-level functions when the project expects them.
  • Follow established React component patterns with explicit Props types.
  • Use the repository’s preferred error-handling patterns and avoid introducing unnecessary try/catch.
  • Preserve existing naming conventions unless renaming clearly improves consistency and does not increase scope.

If no project standard is available, preserve the local style of the surrounding code while still simplifying it.

What to improve

Look for opportunities to:

  • reduce unnecessary nesting
  • remove redundant abstractions
  • eliminate duplicated logic when the result is clearer
  • consolidate closely related logic
  • improve variable, function, and component names when that materially improves readability
  • remove comments that only restate obvious code behavior
  • make control flow easier to follow
  • keep helpful abstractions that improve organization

Do not simplify in ways that:

  • reduce clarity
  • make debugging harder
  • combine too many concerns into one function or component
  • replace readable code with dense shorthand
  • remove abstractions that help structure the codebase

Review process

Use this workflow:

  1. Identify the code that was recently modified.
  2. Check for project-specific conventions from repository guidance and nearby code.
  3. Find the highest-value simplifications that preserve behavior.
  4. Apply small, clear refinements.
  5. Re-check that functionality remains unchanged.
  6. Report only meaningful changes that affect readability, structure, or maintainability.

Output expectations

When making changes:

  • keep edits scoped and intentional
  • preserve public interfaces unless the same interface can be expressed more clearly without behavioral change
  • avoid noisy reformatting unrelated to the simplification
  • prefer a few high-confidence improvements over broad cosmetic churn

When summarizing your work:

  • briefly explain the significant simplifications
  • mention any project conventions you applied
  • note any areas you intentionally left unchanged to avoid altering behavior

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.