ce-simplify-code
Simplify code for clarity, consistency, and maintainability while preserving exact functionality. Prioritize readable, explicit code over overly compact solutions.
Review the changed code for reuse, quality, and efficiency. Fix any issues found. Then verify behavior is preserved by running the project's test suite.
Step 1: Identify scope
Resolve the simplification scope in this order:
- If the user explicitly named a scope (a file, a directory, "the function I just wrote", "the changes from this morning"), use that scope. Treat user-named scope as authoritative — do not widen it.
- Otherwise, in a git repository, default to the diff between the current branch and its base branch (e.g.,
git diff origin/main...or against the configured upstream). This covers the common case of "simplify everything I've added on this feature branch before opening a PR." If the branch has no upstream or base ref, fall back to staged + unstaged changes (git diff HEAD). - Outside a git repository or when no diff is available, review the most recently modified files mentioned by the user or edited earlier in this conversation.
If none of the above produces a non-empty scope, stop and ask the user what to simplify rather than guessing. Use the platform's blocking question tool: AskUserQuestion in Claude Code (call ToolSearch with select:AskUserQuestion first if its schema isn't loaded), request_user_input in Codex, ask_question in Antigravity CLI (agy), ask_user in Pi (requires the pi-ask-user extension). Fall back to numbered options in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question.
Step 2: Launch 3 review agents in parallel
Spawn the three reviewer agents below in a single message via the platform's subagent dispatch primitive — Agent/Task in Claude Code, spawn_agent in Codex — where available; otherwise run the work inline or serially. Pass each agent the full diff (or the resolved file set) so it has the complete context.
Model selection. Use the platform's mid-tier model for these reviewers when the current harness exposes a known override. In Claude Code this is the Sonnet class; in Codex use the current mini/mid-tier model exposed by spawn_agent when known. On platforms where the model-override parameter is unavailable or the model name is unknown or unrecognized, omit the override -- a working pass on the parent model beats a broken dispatch.