--- name: ce-simplify-code description: "Simplify settled, recently changed code for clarity, reuse, quality, and efficiency while preserving behavior. Use after implementation and before review; not for fixing bugs." argument-hint: "[blank to simplify current branch changes, or describe what to simplify]" --- Simplify recently changed code for clarity, reuse, quality, and efficiency while preserving exact behavior. Prioritize readable, explicit code over compact code — fewer lines is not the goal. ## Step 1: Identify scope Resolve the simplification scope in this order: 1. **User-named scope** is authoritative; do not widen it. 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. If none of the above produces a non-empty scope, stop and ask the user what to simplify rather than guessing. Use the host's blocking question tool already in the current tool list (match by capability, not by a host-specific name). Presence in the current tool list is proof the tool exists; never call a user-facing question tool to discover whether it exists. If a matching tool is listed but unloaded, use the host's tool-discovery primitive to load that capability — do not search for another host's tool name. Fall back to numbered options on the host's user-visible chat surface only when no such tool is in the list or a real question call errors. Never silently skip the question. **Preflight.** If the scope has no substantive human-authored code — only documentation, generated or vendored files, dependencies or lockfiles, or mechanical churn — report that there is nothing to simplify and stop without reviewers. For mixed scopes, retain only the code. 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: Run 3 review passes Make three review passes yourself, one after another: code reuse, code quality, and efficiency. For each pass, read its prompt asset from this skill's directory and review the resolved scope (the full diff or file set) as that reviewer, so it has complete context: - `references/personas/code-reuse-reviewer.md` - `references/personas/code-quality-reviewer.md` - `references/personas/efficiency-reviewer.md` Do not paraphrase these rubrics from memory. Read each file and follow it verbatim, or the pass loses the rules that keep it behavior-preserving. Record each pass's findings before starting the next. ## Step 3: Fix issues Proceed only after all three review passes are complete. 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. An interface or data shape that existed only in an earlier iteration of the current unshipped scope is not protected behavior once you verify it has no deployed, persisted, public, external, dependent-branch, or in-repo caller outside the resolved scope. Remove that compatibility path only when every required caller update fits the existing mutation boundary; otherwise preserve 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. **Honor caller-passed structure pins.** A plan path passed with the structure-pin constraint is context, not scope. Preserve its `session-settled:` Key Technical Decisions, including deliberate duplication or separation. ## Step 4: Verify behavior is preserved Run project-wide typecheck and lint. Run tests matched to blast radius: scoped tests for local changes, broader tests for shared or wide-reach changes, and the full suite when the runner cannot scope tests. Report failures with the check name and relevant output. Fix simplification-caused failures or revert the responsible change; never relax assertions, weaken types, or skip tests. If no test suite, lint, or typecheck is configured, state that explicitly in the summary; do not silently skip verification. ## Step 5: Summarize Summarize what was already sound and what improved. Report applied counts by reuse, quality, and efficiency; skipped count; and check outcomes. If nothing changed, say so. Do not use net lines removed as the success metric.