simplify-codeSAFE

From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.

git clone --depth 1 https://github.com/linkxzhou/simplify-code.git ~/.claude/skills/simplify-code

SKILL.md        # Skill definition / 技能定义
references/     # Rules, language notes, behavior traps, examples / 规则、语言要点、行为陷阱、示例
evals/          # Eval cases and fixtures / 评测用例与样例文件

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: simplify-code
description: Simplify, clean up, and refactor existing code in any mainstream language (JS/TS, Python, Java, Go, Rust, C#, C/C++, PHP, SQL, Bash, and more) while preserving behavior and public APIs. Use whenever the user asks to simplify, tidy, refactor, de-nest, deduplicate, remove dead code, shorten code without changing behavior, polish recently written code, modernize syntax safely, or fix code smells (god class, feature envy, primitive obsession), or pastes code saying "make this cleaner" — including 简化代码, 精简代码, 重构, 代码重构, 优化代码可读性, 整理代码, 代码整洁, 去除重复代码, 减少嵌套, 代码坏味道, 这段代码太乱了. Not for performance tuning, bug fixes, new features, translating between languages, configuring linters/formatters, writing tests as the main task, general code review or security audits (read-only simplification assessments are supported), or prose editing (性能优化、修 bug、新功能、代码翻译、配置 lint、写单测、代码审查、文章精简).
license: MIT
---

# Simplify Code

Make code easier to read and change without changing what it does. The target is the *smallest readable equivalent*: fewer concepts, duplicated knowledge, nesting levels, and pointless hops — not the fewest characters. Small safe steps beat big rewrites, because each step can be checked on its own.

## Golden rules

Rules 1–2 outrank everything else in this skill, including the checklists in `references/`. Users ask for cleanup expecting to merge it without re-testing the world; a silent behavior change betrays that trust.

1. **Preserve behavior.** Keep outputs, side effects and their order, error types and messages, null/empty handling, laziness, resource lifetime, and complexity class. A change to any of these is a bug fix or redesign — propose it separately so the user can judge it on its own.
2. **Preserve public APIs.** Exported names, signatures, public fields, error text, wire/DB/CLI formats, and mutability contracts have callers you can't see. Callback→promise, sync→async, panic→`Result`, `null`→exception, parameter objects, and newtypes are API changes: propose, don't apply.
3. **Follow project conventions.** Read applicable `AGENTS.md` / `CLAUDE.md`, linter/formatter config, and neighbouring code; they beat generic advice here because consistency within a codebase matters more than any one style. Project lint/formatter rules also outrank this skill's stylistic preferences (including no nested ternaries): if de-nesting triggers max-depth or another lint rule, try a cohesive helper; otherwise retain the existing form — don't disable lint or rewrite its config. Let the formatter decide layout; hand-formatting creates diff noise that hides the real changes. Use only syntax the configured runtime/compiler supports; don't add dependencies or change config for cleanup.
4. **Prefer clarity over compression.** Avoid nested ternaries, dense one-liners, and chains that hide side effects; the next reader pays for every clever line. Keep helpful boundaries, intention-revealing names, and comments that explain *why*.
5. **Don't over-engineer.** Add abstractions only when they remove real duplication or complexity now; speculative ones are complexity you must maintain. Prefer deleting complexity to relocating it, and deep modules to many shallow helpers.
6. **Respect scope.** Touch the code the user named; if none, the code changed in this session or the working diff. Unrequested edits elsewhere inflate review cost and may collide with others' work, so list out-of-scope smells as suggestions instead.
7. **Report verification honestly.** Claim only checks you actually ran, with the command and result. If something wasn't run, say "not run" and why. A false "verified" leads the user to merge broken code — worse than admitting uncertainty.

## Choose the mode

- **Pasted snippet, no repo:** reason about equivalence directly; check edge inputs mentally, or run a tiny script if tools exist. Return the rewritten code plus notes, and say verification was by reasoning.
- **Read-only simplification assessment:** when asked to analyze, assess simplification opportunities, or report without edits, inspect and prioritize proposals only. Don't edit source, add tests, apply demonstration patches, create branches, commit, or push. Write report files only if requested. Use `references/assessment.md` for scope, priorities, and reporting; this is not a general correctness/security audit.
- **Repository code:** read callers and tests, edit in place, run the project's tests, linters, and type checker. Read `references/assessment.md` when the repository is large or verification is constrained.
- **Already simple:** say so and change nothing (or only trivially safe bits). Inventing churn wastes review time and risks regressions for no benefit.

## Workflow

For read-only assessments, steps 2/6 inspect existing test commands and available evidence; don't add tests or run commands that mutate the checkout. Step 5 produces proposals rather than edits. State the mode and sampled scope before reporting findings.

1. **Understand the contract.** In 1–2 sentences: inputs, outputs, side effects, errors, edge cases. Identify the public surface (`export`, `pub`, `public`, `__all__`, package entry points, callers in other modules).
2. **Secure a safety net.** Run existing tests. For risky repo changes without coverage, add small characterization tests first; if impossible, stay conservative and say so. Edge inputs worth checking: `0`, `''`, `false`, null/None/nil/undefined, NaN, negatives, empty and duplicate collections, duplicate keys, ties, unknown enum values, inherited properties, paths with spaces, size limits.
3. **Plan by payoff and risk.** Dead code and noise → guard clauses/nesting → redundant branches and temporaries → duplication → naming and magic values → conditionals → structure/classes. Use `references/rules.md` for the full catalogue and §20 for the minimum-code procedure.
4. **Apply language idioms.** Open `references/languages.md`, then read only the section for the language at

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

declared (2 observation(s))

Dependencies

pinned

Secrets in source

none-found

Findings (1)

Gates applied: no_behavioural_pass, no_license.