Rename a concept across the whole project: learn what the term refers to,
propose several candidate names and defend them, get the user's pick, then apply
it everywhere the old term appears in code, prose, docs, the glossary, and
skills.
Target
jj show --git
Arguments: $ARGUMENTS
The arguments name the term to rename and optionally a reason or a preferred
name. Rename the term named in the arguments if given. Otherwise rename a term
discussed in the conversation, or a term introduced by the changes in the
current commit shown above. If you cannot determine which term to rename, ask
the user and stop.
Principles
- Rename the concept, not the string. The old term marks one idea. Find every
place that idea is named, including spellings the first search misses
(abbreviations, plurals, verb forms, adjectives) and skip places the same
letters mean something else
- One concept per pass. If the search shows the term covers two distinct ideas,
that is a split, not a rename: say so and get the user's decision on both
names before editing
- The new name comes from the domain. Prefer the word a practitioner already
uses for this thing over an invented or borrowed one (see
/concretize)
- Check the name against prior art. A name that already means something else in
the language, the ecosystem, or the codebase costs the reader a translation
- Candidates first, edits second. Never start renaming on a name you chose
yourself. The user picks
- All or nothing. A half-applied rename leaves two words for one concept, worse
than either name alone. Finish it or revert it
These aren't exhaustive. Reason from first principles when none fits cleanly.
Workflow
- Establish what the term means. Read its definition and its main uses before
proposing anything, because a rename chosen from the word alone names the
wrong thing
- Inventory every occurrence (see "Finding every occurrence"). Do this before
proposing names: the count and spread show how big the change is, and the
uses reveal whether the term covers one concept or two
- If the term covers more than one concept, report the split and ask the user
how to name each part before continuing
- Propose three to five candidates (see "Proposing candidates"). Present them
with
AskUserQuestion and stop until the user picks. Accept a name they
supply instead
- Sweep the chosen name through every occurrence from step 2 (see "Applying the
rename"). Work file by file and keep the inventory as your checklist
- Re-run the searches from step 2. Every remaining hit is either a miss to fix
or a place the letters mean something else. Note those in the report
- Run the covering tests and a typecheck if any code changed
- Report: the old term, the new name and why it won, counts by category (code
identifiers, comments, prose, docs, glossary, skills, filenames), any public
name deliberately kept, and any occurrence left alone because the letters
meant something else
Finding every occurrence
Search case-insensitively for the term and each of its forms, then widen:
- Identifier casings:
fooBar, FooBar, foo_bar, foo-bar, FOO_BAR
- Morphological forms: plurals,
-ing/-ed verb forms, adjectives, and the
agent noun (sweep, sweeps, sweeping, sweeper, swept)
- Abbreviations and initialisms the codebase uses for it, including inside
longer identifiers
- Filenames and directory names, test fixture names, and snapshot files
- Non-code text: comments, docstrings, README and docs,
glossary.md,
CLAUDE.md, .claude/skills, commit templates, CLI help text, error
messages, and log strings
- Externally visible names: exported API, config keys, CLI flags, database
columns, serialized field names, and public URLs
Group the hits by category as you go. The groups become the checklist for the
sweep and the shape of the report.
Proposing candidates
Give each candidate one short paragraph:
- What it claims the thing is, in the domain's terms
- What it reads like at the call site or in a sentence: one line from the code
or prose, rewritten
- Prior art: what the word already means in this language, ecosystem, or
codebase, and whether that helps or collides. Search the codebase. Search the
web when the term is likely to be a term of art
- What it costs: ambiguity it introduces, forms it lacks (a noun with no verb
form), or length at the call sites where it appears most
Include the current name as a candidate when keeping it is defensible, and say
what would have to be true for that to be the right call. State your
recommendation and why.
Applying the rename
- Code identifiers: treat each as a behavior-preserving rename and update every
reference. For a name callers outside the project depend on, keep the old name
as an alias and say so in the report rather than breaking them silently
- Comments and prose: rewrite the sentence, don't substitute the word. The old
name shaped the phrasing around it, and a swap leaves an awkward or now-wrong
sentence
- Files and directories: rename them too, and update every import, link, and
path reference
glossary.md: update the entry to the new term and list the old term under
aliases to avoid. If there is no glossary and the project would benefit,
suggest /ubiquitize-language rather than starting one mid-rename
.claude/skills and CLAUDE.md: future sessions read these. Renaming
everywhere else and leaving them stale reintroduces the old word
- Strings users see (CLI help, errors, docs): rename them, and call them out
separately in the report
- Leave alone: quoted external material, historical commit messages, changelog
entries about past releases, and vendored code. Note them in the report
Fixing mistakes
- A test or typecheck breaks: a reference was missed, or the name collides with
an existing one in scope. Fix the reference, or pick a non-colliding form and
tell the user the chosen name needed adjusting
- A search for the old term still hits after the sweep: finish the sweep. Only
homographs, quoted material, and history may remain
- The new name reads wrong once applied everywhere: stop and report it rather
than half-reverting. The user picked the name and should decide whether to
revert the whole sweep or continue
1---2name: rename-concept3description: Rename a concept everywhere: propose candidate names with tradeoffs, let the user pick, then sweep the winner through identifiers, prose, docs, and skills.4---56Rename a concept across the whole project: learn what the term refers to,7propose several candidate names and defend them, get the user's pick, then apply8it everywhere the old term appears in code, prose, docs, the glossary, and9skills.1011# Target1213```!14jj show --git15```1617Arguments: $ARGUMENTS1819The arguments name the term to rename and optionally a reason or a preferred20name. Rename the term named in the arguments if given. Otherwise rename a term21discussed in the conversation, or a term introduced by the changes in the22current commit shown above. If you cannot determine which term to rename, ask23the user and stop.2425# Principles2627- Rename the concept, not the string. The old term marks one idea. Find every28 place that idea is named, including spellings the first search misses29 (abbreviations, plurals, verb forms, adjectives) and skip places the same30 letters mean something else31- One concept per pass. If the search shows the term covers two distinct ideas,32 that is a split, not a rename: say so and get the user's decision on both33 names before editing34- The new name comes from the domain. Prefer the word a practitioner already35 uses for this thing over an invented or borrowed one (see `/concretize`)36- Check the name against prior art. A name that already means something else in37 the language, the ecosystem, or the codebase costs the reader a translation38- Candidates first, edits second. Never start renaming on a name you chose39 yourself. The user picks40- All or nothing. A half-applied rename leaves two words for one concept, worse41 than either name alone. Finish it or revert it4243These aren't exhaustive. Reason from first principles when none fits cleanly.4445# Workflow46471. Establish what the term means. Read its definition and its main uses before48 proposing anything, because a rename chosen from the word alone names the49 wrong thing502. Inventory every occurrence (see "Finding every occurrence"). Do this before51 proposing names: the count and spread show how big the change is, and the52 uses reveal whether the term covers one concept or two533. If the term covers more than one concept, report the split and ask the user54 how to name each part before continuing554. Propose three to five candidates (see "Proposing candidates"). Present them56 with `AskUserQuestion` and stop until the user picks. Accept a name they57 supply instead585. Sweep the chosen name through every occurrence from step 2 (see "Applying the59 rename"). Work file by file and keep the inventory as your checklist606. Re-run the searches from step 2. Every remaining hit is either a miss to fix61 or a place the letters mean something else. Note those in the report627. Run the covering tests and a typecheck if any code changed638. Report: the old term, the new name and why it won, counts by category (code64 identifiers, comments, prose, docs, glossary, skills, filenames), any public65 name deliberately kept, and any occurrence left alone because the letters66 meant something else6768# Finding every occurrence6970Search case-insensitively for the term and each of its forms, then widen:7172- Identifier casings: `fooBar`, `FooBar`, `foo_bar`, `foo-bar`, `FOO_BAR`73- Morphological forms: plurals, `-ing`/`-ed` verb forms, adjectives, and the74 agent noun (`sweep`, `sweeps`, `sweeping`, `sweeper`, `swept`)75- Abbreviations and initialisms the codebase uses for it, including inside76 longer identifiers77- Filenames and directory names, test fixture names, and snapshot files78- Non-code text: comments, docstrings, README and docs, `glossary.md`,79 `CLAUDE.md`, `.claude/skills`, commit templates, CLI help text, error80 messages, and log strings81- Externally visible names: exported API, config keys, CLI flags, database82 columns, serialized field names, and public URLs8384Group the hits by category as you go. The groups become the checklist for the85sweep and the shape of the report.8687# Proposing candidates8889Give each candidate one short paragraph:9091- What it claims the thing is, in the domain's terms92- What it reads like at the call site or in a sentence: one line from the code93 or prose, rewritten94- Prior art: what the word already means in this language, ecosystem, or95 codebase, and whether that helps or collides. Search the codebase. Search the96 web when the term is likely to be a term of art97- What it costs: ambiguity it introduces, forms it lacks (a noun with no verb98 form), or length at the call sites where it appears most99100Include the current name as a candidate when keeping it is defensible, and say101what would have to be true for that to be the right call. State your102recommendation and why.103104# Applying the rename105106- Code identifiers: treat each as a behavior-preserving rename and update every107 reference. For a name callers outside the project depend on, keep the old name108 as an alias and say so in the report rather than breaking them silently109- Comments and prose: rewrite the sentence, don't substitute the word. The old110 name shaped the phrasing around it, and a swap leaves an awkward or now-wrong111 sentence112- Files and directories: rename them too, and update every import, link, and113 path reference114- `glossary.md`: update the entry to the new term and list the old term under115 aliases to avoid. If there is no glossary and the project would benefit,116 suggest `/ubiquitize-language` rather than starting one mid-rename117- `.claude/skills` and `CLAUDE.md`: future sessions read these. Renaming118 everywhere else and leaving them stale reintroduces the old word119- Strings users see (CLI help, errors, docs): rename them, and call them out120 separately in the report121- Leave alone: quoted external material, historical commit messages, changelog122 entries about past releases, and vendored code. Note them in the report123124# Fixing mistakes125126- A test or typecheck breaks: a reference was missed, or the name collides with127 an existing one in scope. Fix the reference, or pick a non-colliding form and128 tell the user the chosen name needed adjusting129- A search for the old term still hits after the sweep: finish the sweep. Only130 homographs, quoted material, and history may remain131- The new name reads wrong once applied everywhere: stop and report it rather132 than half-reverting. The user picked the name and should decide whether to133 revert the whole sweep or continue