How to use the ce-simplify-code agent skill for code review

What the skill makes the agent do

The skill reviews code that was just implemented or changed, usually the current branch compared with its base. It runs several parallel reviewer subagents. Each one follows a detailed rubric covering code reuse, code quality, efficiency, test value, and comment value. The agent then applies the fixes it judges worthwhile.

The skill is built around keeping behavior the same. Each fix must preserve outputs, errors, side effects, and ordering, and if that cannot be established the fix is skipped. It also never removes safety checks such as trust-boundary validation, data-loss protection, security checks, or accessibility affordances.

It does not fix bugs or failing tests. The skill says so directly and sends those to a separate skill, ce-debug.

Install the ce-simplify-code skill

Download the skill ZIP from this page and unzip it. You can install it in one of two places. For all your projects, put the unzipped folder in ~/.claude/skills/. For a single project, put it in that project's .claude/skills/ folder.

In the Claude apps, you can instead upload the skill under Settings → Capabilities → Skills.

• Personal install: ~/.claude/skills/
• Project install: .claude/skills/ inside your repository

Trigger the skill with a natural request

You do not need a special command. Ask the agent in plain language, and say what scope you want. The skill's argument hint lists the accepted inputs: leave the scope blank to review the current branch changes, or describe what to simplify or audit. Two optional tokens also exist for automated use: mode:pipeline and proof-test:<path>.

If you ask for a run in your own message, the skill works in standalone mode. It reports its findings before editing anything, unless your request says to just fix them. Runs started by another skill or by the agent itself use pipeline mode, which applies fixes without waiting and returns a summary.

• Simplify my changes on this branch before I open a pull request.
• Audit the tests in the payments folder for ones that add no value.
• Check the comments in src/parser for ones that are out of date or redundant.
• Simplify what I changed, but report first and don't edit anything yet.

Understand the scope and what gets skipped

The skill chooses its scope in order. A scope you name is used as is and not widened. Otherwise, in a git repository it uses the current branch compared with its base. Without a usable base it uses staged and unstaged changes. Outside git, it uses files you named or files edited earlier in the conversation.

A preflight check skips changes with no substantive human-written code, such as only documentation, generated or vendored files, dependencies, or lockfiles. For mixed changes, only the code and its tests are kept.

Review, fix and verify

The skill launches the reviewers in parallel where your agent supports subagents. Codex and similar agents are handled too. If subagents are not available, the reviews run inline or one after another. The test-value reviewer runs only when tests are in scope, and the comment reviewer only when comments are in scope.

After fixes, the agent runs the project's typecheck and lint, then tests matched to the size of the change. If no test suite, lint, or typecheck is configured, the summary says so instead of skipping quietly. Its summary reports applied counts by reuse, quality, efficiency, tests, and comments, plus skipped findings and check results. It does not use net lines removed as a success measure.

• Comments are deleted by default unless they are license headers, notes on outside constraints, public API docs, issue or spec links, or tool directives.
• Tests the current work relies on as proof are protected from changes.

Safety notes: scripts and network

The skill's own documentation says it runs no scripts and uses no network. It is made of instruction files and reviewer prompts. It does run your project's own typecheck, lint, and test commands during verification, so those run in your environment.

Review the summary before committing. In standalone mode you can read the report and choose which findings to apply.

Tips for good results

Run it on a feature branch in a git repository, so the agent can compare your branch with its base. Give it a clear scope when the change is large. If you are auditing old tests or comments, name the folder you want checked.

If a change could alter behavior and you need to approve it first, ask for a standalone report before any edits.

• Keep your project's typecheck, lint, and test commands working so verification has something to run.
• Use ce-debug, not this skill, for bugs and failing tests.