/ce-simplify-code

name: ce-simplify-code
description: "Simplify code for clarity, reuse, quality, and efficiency while preserving behavior, and prune tests and comments that carry no value. Use after implementation and before review, or to audit tests or comments in any part of a repo; use ce-debug for bugs."
argument-hint: "[blank for current branch changes, or describe what to simplify or audit] [mode:pipeline] [size-cutoff:<N>] [proof-test:<path>]"

Simplify code for clarity, reuse, quality, and efficiency, and prune tests and comments that carry no value, while preserving exact behavior. Prioritize readable, explicit code over compact code — fewer lines is not the goal.

Mode

Strip a `mode:pipeline` token, a `size-cutoff:<N>` token, and every `proof-test:<path>` token from the input before reading the rest as the scope. The proof-test path is context for Step 3, never scope; a caller may pass several.

• **Pipeline** when `mode:pipeline` is present, or when no one asked for this run in their own current message: a step of another skill, or a run the agent starts itself, such as at a completion boundary. Work only on the current work, apply fixes without asking or waiting, and return the Step 5 summary to the caller. That summary is for the caller's record; never paste it into a commit, PR body, or other artifact.
• **Standalone** when the user's own current message asked for this run. Their request sets the scope and focus. Report findings before editing anything, unless the request says to just fix them. Read `references/standalone-report.md` now, and again before applying any reported finding.

Step 1: Identify scope

Resolve the scope in this order:

1. **User-named scope** is authoritative; do not widen it. In standalone mode it may be the whole repo, an area, or a path. 2. **Otherwise, in git**, use the current branch versus its base. Without a usable base, use staged and unstaged changes (`git diff HEAD`). 3. **Outside git or without a diff**, use files the user named or that were edited earlier in the conversation.

In pipeline mode the scope is what the caller passed, else the branch diff. Within it, prune only tests and comments the current work added or changed.

If none of the above produces a non-empty scope, pipeline mode reports "nothing to simplify" and returns. Standalone mode asks the user what to simplify, as `references/standalone-report.md` describes.

**Preflight.** Code, for this skill, is human-authored source in a programming language that a compiler, interpreter, or shell runs, such as TypeScript, Python, shell, or SQL. Tests written in one are code too. Nothing else is code, whatever it is for. Prose is not code, in any format, including markdown that agents read: skills, prompts, and agent instructions. Neither are documentation, plans, data, configuration, generated or vendored files, dependencies, or lockfiles. If the scope holds no code, or only mechanical churn in code, report that there is nothing to simplify and stop without reviewers. For mixed scopes, retain only the code and the test fixtures it uses. This check is about the kind of change, never its size: explicit small scopes still run, and any size or cost threshold is the caller's to set.

When the platform's task-tracking capability is available, show the review, apply, and verification outcomes without creating one task per reviewer. Otherwise continue without simulating a task list in chat.

Step 2: Launch review agents in parallel

Dispatch each reviewer as its own generic subagent via the platform's subagent primitive (`Agent`/`Task` in Claude Code, `spawn_agent` in Codex). Run reviews inline only when the platform has no subagent primitive, or when a dispatch fails as `references/reviewer-dispatch.md` describes. For each reviewer, read its prompt asset from this skill's directory and pass the **full file content** as the subagent's prompt, together with the resolved scope (the full diff or file set), the mode, any proof test, the user's constraints, and the project standards governing the scope (or their file paths):

• `references/personas/code-reuse-reviewer.md`
• `references/personas/code-quality-reviewer.md`
• `references/personas/efficiency-reviewer.md`
• `references/personas/test-value-reviewer.md`, when the scope holds tests
• `references/personas/comment-reviewer.md`, when the scope holds comments

A standalone request about only tests or only comments runs only that reviewer.

Do not paraphrase these rubrics from memory. Read each file and pass it verbatim, or the reviewer loses the rules that keep the pass behavior-preserving.

When the input carried `size-cutoff:<N>`, read `references/single-pass.md` before dispatching; it decides whether the full team or one combined reviewer runs.

Read `references/reviewer-dispatch.md` before dispatching; it covers the reviewers' model, a full harness, releasing review agents, and the permission mode.

Step 3: Fix issues

Proceed only after every review outcome is complete, whether returned by subagents or produced inline. In standalone mode, unless the request says to just fix them, report and stop here. Otherwise apply worthwhile findings directly; record false positives and low-value findings as skipped without asking the user.

Inspect beyond the resolved scope when needed to evaluate a finding, but edit only that scope and the import/export lines it needs. For a user-named file or directory scope, those import/export lines must also be inside it; skip any fix that would edit outside the mutation boundary.

Each fix must preserve outputs, errors, side effects, and ordering. If that cannot be established, skip it.

**Never simplify away a safety check.** Preserve trust-boundary validation, data-loss protection, security checks, and accessibility affordances. Skip any finding that would thin or remove one.

**Protect the proof tests.** In pipeline mode, each test the current work relied on to show its change works stays exactly as it is