codex-simplify

name	codex-simplify
description	Review recently changed files for code reuse, quality, and efficiency issues, then fix them. Use when implementation is already complete and you want a final cleanup pass that mirrors Claude Code's `/simplify` behavior as closely as Codex can, without overriding Claude's native `/simplify`.

Codex Simplify

Run a post-implementation cleanup pass over recently changed files.

This skill is the Codex approximation of Claude Code's bundled /simplify behavior. It intentionally lives outside .claude/skills/ and uses the non-conflicting name codex-simplify so Claude Code keeps its native /simplify command.

Preserve the public contract:

• target recently changed files
• review for reuse, quality, and efficiency
• use three independent review passes
• aggregate findings
• apply fixes

Treat any user-supplied focus, such as memory efficiency, dead code, duplication, or readability, as extra weighting rather than a replacement for the core three review lenses.

When to use

Use this skill when:

• the code already exists
• the implementation or bug fix is already done
• the user wants a cleanup or refactoring pass rather than new feature work
• a workflow calls for a /simplify-style pass after review approval

Do not use this skill as a substitute for initial implementation, plan compliance review, or full validation.

Target file selection

Approximate "recently changed files" with this priority order:

1. Tracked unstaged changes in the current worktree
2. Tracked staged changes
3. Untracked files clearly related to the current task
4. If the tree is clean, files changed by the most recent commit

Use git to discover the set. Prefer file lists equivalent to:

git diff --name-only --diff-filter=ACMR
git diff --cached --name-only --diff-filter=ACMR
git ls-files --others --exclude-standard
git diff --name-only --diff-filter=ACMR HEAD~1..HEAD

Deduplicate the list. Exclude generated artifacts, lockfiles, build output, and unrelated files unless the user explicitly asks for them.

If there are no relevant changed files, stop and report that codex-simplify has nothing to do.

Review workflow

Run three independent review passes over the same target file set:

1. Reuse pass Look for duplication, repeated logic, avoidable branching, and places where a simpler shared helper or existing abstraction should be used.
2. Quality pass Look for confusing structure, dead code, weak naming, brittle conditionals, unnecessary complexity, and maintainability problems.
3. Efficiency pass Look for avoidable work, redundant allocations, repeated I/O, wasteful data transformations, and obvious performance footguns.

If Codex subagents are explicitly available and appropriate, run these as three parallel subagents. Otherwise, perform the three passes locally but keep them logically separate until aggregation.

Each pass should:

• stay inside the changed-file scope unless a tiny adjacent edit is required for correctness
• prefer concrete, behavior-preserving improvements over style-only opinions
• respect existing project patterns unless the changed code clearly violates them
• treat any user-supplied focus as extra weighting, not as permission to ignore reuse, quality, or efficiency entirely

Aggregation rules

After the three passes, combine findings into one action set:

• deduplicate overlapping suggestions
• prefer the smallest safe change that resolves the issue
• reject churn that only restyles code without improving it
• reject broad architectural rewrites unless they are clearly necessary to remove duplication or complexity introduced by the recent change
• preserve behavior, tests, and plan intent

If two fixes conflict, prefer the version that is simpler, lower-risk, and more local to the changed code.

Applying fixes

Apply the agreed changes directly.

Default priorities:

1. Remove duplication introduced by the recent change
2. Delete dead code or unreachable branches
3. Collapse unnecessary indirection
4. Tighten inefficient hot-path logic
5. Improve names or local structure where that meaningfully reduces confusion

Do not:

• expand the task into unrelated refactors
• rewrite stable untouched modules just because they could be cleaner
• change public behavior intentionally
• introduce speculative abstractions

Add or adjust focused tests only when needed to preserve behavior during a non-trivial simplification.

Output contract

At the end:

• summarize what changed
• group the rationale under reuse, quality, and efficiency
• mention any fallback used to determine the target file set
• explicitly state that verification should be rerun after the pass

If the invoking workflow already owns verification, stop after the cleanup pass and hand back the changed files plus the rerun-verification reminder.