Naming Review

Review changed identifiers for the target: $ARGUMENTS.

Recommend renames only where the current name hides important meaning, creates ambiguity, or misstates behavior. A name that is merely short is not a finding.

Establish Scope

1. Identify the requested commit, range, branch diff, staged diff, or working-tree change. For a single commit, compare against its first parent.
2. Run git status --short before reviewing. If the worktree holds later edits, inspect them separately and do not report names already corrected.
3. Build the candidate set from the diff's added lines only. A declaration is a candidate when the diff adds the line that declares it, or when the diff changes what that declaration holds or does. Widened use is not a candidate: a pre-existing declaration stays out of scope even when the change adds call sites, moves it, reindents it, or alters surrounding code.
4. Verify each candidate before reporting it. Run git log -1 -S'<name>' -- <path> or git blame on the declaration line and confirm the declaring commit is the one under review. Drop any candidate that predates it.
5. Read each candidate in its full scope and inspect representative call sites, types, return values, comments, and tests. Use surrounding code to judge a candidate, never to add one.
6. Use rg where available; fall back to grep or find.

The Project's Lexicon

A name has to agree with the vocabulary the project already uses, not merely read well on its own. Establish the established terms before recommending anything.