メニュー
Workflow for safely renaming symbols (functions, types, classes, interfaces, constants, variables) across a codebase. Uses repo_map, batch_symbols, and build_check to ensure every consumer is updated and nothing breaks.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/ZaxbyHub/opencode-swarm --skill safe-renameコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Run a graph-guided, tool-augmented PR review using context packing, parallel exploration, mandatory repository-agnostic risk-family coverage with dispatch scaled to diff size and risk, independent reviewer validation, critic challenge, and metrics writeback. Use for deep pull request review with low false-positive tolerance and high recall in any repository, on any agent harness (structured lane controller, native parallel subagents, or single-context sequential passes).
Apply when committing, pushing, opening or updating a PR, writing a pull request, creating release notes, or closing out remote CI. Enforces the opencode-swarm invariant audit, release-note fragment workflow, full validation suite, issue comment requirement, and post-PR lifecycle rules.
Enable a high-quality swarm-like Claude Code workflow for the current session, and optionally execute a task immediately using that mode. Uses parallel subagents for breadth, independent reviewer validation for precision, and critic challenge for final confidence. Use when the user wants swarm-like behavior, higher review rigor, or maximum quality without sacrificing Claude Code speed.
SOC 職業分類に基づく
SKILL.md を表示中
| name | safe-rename |
| description | Workflow for safely renaming symbols (functions, types, classes, interfaces, constants, variables) across a codebase. Uses repo_map, batch_symbols, and build_check to ensure every consumer is updated and nothing breaks. |
| effort | small |
| generated_from_knowledge | [] |
| source_knowledge_ids | ["20f7da40-02e0-4da8-9310-a78eb87ca81e"] |
| generated_at | 2026-06-14T16:50:00.000Z |
| confidence | 0.8 |
| status | active |
| version | 4 |
| skill_origin | generated |
| provenance_note | Re-linked to current knowledge entries (version 4). The original source ID 1eb9f867... is no longer present in the active knowledge store. The skill body and behavior are unchanged; only source_knowledge_ids metadata was updated to point to the current lesson about updating test data when a fix changes expectations, which is directly relevant to safe rename verification. |
Guides a systematic, tool-augmented workflow for renaming exported symbols across a codebase without silently breaking consumers, tests, or downstream builds.
Do NOT use for:
| Tool | Purpose |
|---|---|
repo_map (action: importers) | Find every file that imports from the target file |
repo_map (action: blast_radius) | Find transitive dependents for high-risk renames |
symbols | List the full exported API surface of the target file |
batch_symbols | Bulk symbol extraction across multiple affected files |
search | Find literal occurrences of the old symbol name across the codebase |
suggest_patch | Preview changes before applying (dry-run) |
apply_patch | Apply rename patches to consumer files |
edit | Fallback for one-at-a-time rename edits when apply_patch is not suitable |
build_check (mode: typecheck) | Verify the rename does not break compilation |
test_runner | Run tests on affected files after rename |
repo_map with action importers and file set to the target file path.
This returns every file that imports from the target, with line numbers and
import metadata.repo_map with action blast_radius to understand
transitive dependents.symbols on the target file (with exported_only: true) to see every
exported symbol. This helps confirm the exact name, signature, and whether
the symbol is re-exported.batch_symbols on the consumer files identified in Step 2 to understand
how they import and use the symbol.import { OldName } from './target'import * as ns from './target' then ns.OldNameobj['OldName'] (see Limitations)edit.apply_patch:
suggest_patch to preview the rename changes for the consumer file,
then apply the patch with apply_patch.Before considering the rename complete:
suggest_patch to preview any remaining rename changes before applying
with apply_patch, ensuring the patch set is correct.build_check with mode: "typecheck" and scope: "changed".
build_check with mode: "both" if the project uses a build step
(compilation + typecheck).test_runner with scope: "impact" or scope: "graph" on the changed
files to verify no tests break.search for the old symbol name across the entire codebase to
confirm zero remaining references (excluding comments, changelogs, and
docs/releases/ history fragments).When consolidating types from sibling files (e.g., extracting a shared type
from evidence.ts and runner.ts into a new types.ts in the same
directory), verify import direction before creating the shared module.
If the new module imports anything from either sibling, you create a circular
dependency that silently breaks the module graph.
Example of the trap:
// types.ts — imports from a sibling
import { SomeClass } from './runner'; // ← runner.ts will import from types.ts
export interface MyType { handler: SomeClass }; // circular!
Verification steps:
repo_map (action: dependencies)
on each sibling file to understand what it imports.repo_map (action: importers) on the new shared
module to verify it has no import edges pointing back to the siblings.build_check (mode: typecheck) to confirm no circular dependency
errors._types.ts that has no imports
from the directory).Why this matters: During PR #1702, consolidating types from sibling files
in src/turbo/lean/ created a circular dependency between evidence.ts,
runner.ts, and the extracted types module. The typecheck caught it, but the
fix required restructuring the extraction.
This workflow has the following known gaps:
repo_map importers and search find imports by file path, but they do not
resolve renamed imports:
import { X as Y } from './target'; // Y is an alias for X
If you rename X to Z, the search will not find the Y alias. You must
manually check for aliased imports by searching for { X as patterns.
This workflow is text-based, not AST-based. In TypeScript, structural typing means
a variable typed as { name: string } satisfies any interface with that shape,
regardless of the interface name. Renaming the interface name does not require
updating these structural usages, but the workflow may flag them as "missed
references" in Step 7.
References via string literals, reflection, or computed property access are invisible to static search:
obj['oldName'] // string-based property access
Reflect.get(target, 'oldName') // reflection
If the renamed symbol is accessed dynamically anywhere, those references will
not be found by search or repo_map. Use grep for the string form of the old
name to catch these cases.
If a symbol is re-exported through an index file (export { X } from './X'),
the re-export line and all downstream consumers of the re-export must also be
updated. The repo_map blast_radius action helps here, but you must manually
verify re-export chains.
The old symbol name may appear in:
These are outside the scope of this workflow but should be considered for high-impact renames.
Before marking a rename complete, verify every item:
build_check typecheck passes with no errorssearch for old name returns zero stale code references