65 lines
4.5 KiB
Markdown
65 lines
4.5 KiB
Markdown
---
|
|
name: simplify-code
|
|
description: Simplify recently changed code without changing behavior. Use when asked to clean up, clarify, streamline, refactor, or review an uncommitted diff, staged changes, changes against a Git ref or branch, the last commit, or specified changed files. Restrict edits to changed lines, follow repository guidance, preserve public APIs and semantics, and verify the result with the project's tests and checks.
|
|
---
|
|
|
|
# Simplify Code
|
|
|
|
Improve the readability and maintainability of a Git-scoped change while preserving its behavior. Treat the existing diff as the edit boundary, not as permission to refactor the surrounding code.
|
|
|
|
## Resolve the scope
|
|
|
|
1. Find the repository root with `git rev-parse --show-toplevel` and work from it.
|
|
2. Read applicable repository instructions such as `AGENTS.md` and `CLAUDE.md`, including any nearer files that govern the changed paths.
|
|
3. Preserve unrelated worktree changes. Never reset, restore, discard, stage, or commit changes unless the user explicitly asks.
|
|
4. Select one base scope from the request:
|
|
- Default, including staged and unstaged tracked changes: `git diff HEAD`
|
|
- Staged only: `git diff --cached`
|
|
- Against a ref or branch: `git diff <ref>`
|
|
- Last commit: `git diff HEAD~1..HEAD`
|
|
5. If the user names files, append `-- <paths...>` and exclude every other path.
|
|
6. List statuses with the matching `git diff --name-status` command. For renames or copies, use the destination path.
|
|
7. If the default scope is empty and the request refers generally to recent changes, fall back to `HEAD~1..HEAD`. State in the final summary that the last commit was used. Do not use this fallback for an explicitly staged, ref, or file-scoped request.
|
|
8. If the resulting scope is empty, report that there is nothing to simplify and stop.
|
|
|
|
Use `git diff --unified=0 --no-ext-diff <scope> -- <path>` to identify current-file line ranges from each hunk's `+start,count` coordinates. Treat an omitted count as one line and a zero count as a deletion-only hunk with no current lines. Treat an added file as fully in scope. If ranges touch or overlap, treat them as one range.
|
|
|
|
Do not hand-edit binary files, generated output, minified files, vendored code, lockfiles, or snapshots unless the user specifically includes them and the repository expects manual edits. Report skipped files briefly.
|
|
|
|
## Simplify within the boundary
|
|
|
|
Inspect surrounding code for context, but modify only the changed current-file ranges. Work one file at a time so line movement remains manageable. Recalculate that file's diff after editing and confirm no simplification edit escaped the original changed regions.
|
|
|
|
Prioritize concrete improvements:
|
|
|
|
- Reduce unnecessary nesting, branching, duplication, and intermediate state.
|
|
- Replace unclear names when every required reference can be changed inside the allowed scope.
|
|
- Consolidate logic that is already one concern; keep distinct concerns separate.
|
|
- Remove dead or redundant code and comments that merely narrate syntax.
|
|
- Retain comments that explain intent, constraints, business rules, or non-obvious behavior.
|
|
- Prefer straightforward control flow over clever expressions; avoid nested ternaries.
|
|
- Follow established project patterns instead of introducing a new abstraction or style.
|
|
|
|
Preserve observable behavior, error handling, side effects, ordering, concurrency behavior, types, serialization formats, and public APIs. Do not add features or broaden the task. Do not remove a useful abstraction merely to reduce line count.
|
|
|
|
If an improvement requires touching unchanged code, leave the code alone and mention the opportunity in the final summary. If no worthwhile in-scope improvement exists, make no edit to that region.
|
|
|
|
## Verify
|
|
|
|
1. Review the final diff for every edited file and run `git diff --check` with the same scope where applicable.
|
|
2. Run the narrowest relevant formatter, linter, type checker, and tests first, using repository-provided commands.
|
|
3. Run the broader project verification suite when practical.
|
|
4. If verification fails, determine whether the failure was caused by the simplification. Fix in-scope regressions; otherwise preserve the failure output and report it accurately.
|
|
5. Reconfirm that behavior and public interfaces did not change and that unrelated files remain untouched.
|
|
|
|
## Report
|
|
|
|
Summarize:
|
|
|
|
- the Git scope reviewed;
|
|
- the simplifications made and why they improve clarity;
|
|
- checks and tests run, with their results;
|
|
- skipped files, pre-existing failures, or worthwhile out-of-scope improvements.
|
|
|
|
Do not claim a simplification when the code was already clear enough to leave unchanged.
|