agentsclimarketplace

Simplify code safely

Skill K95M65/AI_ONBOARD/skills/simplify-code-safely

Portable agent workflow framework for Codex, Claude Code, and OpenCode—shared project context, focused skills, independent review, and safe updates.

Install
npx -y skills add K95M65/AI_ONBOARD --skill simplify-code-safely

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Simplifies existing code while preserving externally observable behavior, public contracts, and required performance. Use when reducing accidental complexity, removing dead or duplicated logic, clarifying control flow, shrinking an over-engineered change, or performing a focused behavior-preserving refactor; do not use for feature development, architecture replacement, or read-only code review.

SKILL.md

2.7 KB, as published. Nobody here has run it

Simplify code safely

Make the code easier to understand without quietly changing what it does.

Establish the behavior boundary

Read the project instructions, callers, tests, public interfaces, error behavior, side effects, data formats, performance constraints, and compatibility requirements. State the simplification target and what must not change. If behavior is unclear, characterize it with focused tests before refactoring.

Find accidental complexity

Look for:

  • dead code, unreachable branches, stale flags, and unused indirection;
  • duplicated rules that represent the same concept;
  • conditionals that can become early exits or explicit state transitions;
  • abstractions with one caller and no meaningful policy boundary;
  • misleading names, hidden side effects, and values recomputed across layers;
  • comments that compensate for unclear structure rather than explain intent.

Do not collapse distinct domain concepts merely because their current implementations look similar.

Simplify in small steps

  1. Record a passing baseline for the relevant checks.
  2. Make one coherent transformation at a time.
  3. Prefer deletion, direct control flow, precise names, and existing language features.
  4. Preserve public APIs, error semantics, ordering, concurrency, persistence, and security checks unless the user explicitly includes them in scope.
  5. Run the narrow checks after each risky transformation.
  6. Review the final diff for accidental behavior changes and unnecessary churn.

Avoid speculative frameworks, generic helpers without a stable concept, broad formatting changes, and dependency upgrades unrelated to the simplification.

Prove the result

Run focused tests and the relevant broader suite. Compare before/after behavior, and measure performance only when performance is part of the contract. Report what became simpler—deleted branches, reduced state, removed duplication, or clearer ownership—without using line count as the only quality measure.

Use a separate reviewer agent when independent code review is requested. This skill edits code; the reviewer remains read-only.

Finish when the behavior boundary still holds, the diff is smaller or conceptually clearer, and every claimed improvement is visible in the code rather than asserted from taste.

Gives 0 of the 12 instructions most refactoring skills give

Counted across 521 of the 525 authors here whose files we hold, read 2026-08-06

  • run tests after each changein 59 of 521, across 56 files
  • write tests before refactoringin 27 of 521, across 24 files
  • preserve external behaviorin 26 of 521, across 22 files
  • remove dead codein 25 of 521, across 24 files
  • make small incremental changesin 20 of 521, across 17 files
  • break the implementation into tiny commitsin 18 of 521, across 5 files
  • ask the user about alternative optionsin 17 of 521, across 4 files
  • create a GitHub issue with the planin 17 of 521, across 4 files
  • explore the repository to verify assertionsin 17 of 521, across 4 files
  • interview the user about the refactorin 16 of 521, across 3 files
  • check the codebase for test coveragein 16 of 521, across 3 files
  • refactor one thing at a timein 16 of 521, across 12 files

Said here and by no other author read

  • write focused tests for unclear behavior before refactoring
  • find and remove accidental complexity
  • prefer deletion, direct control flow, and precise names
  • preserve public APIs, error semantics, and security checks
  • run focused tests after each risky transformation
  • run focused tests and the broader suite

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.