用途：在较大代码库中批量机械重命名标识符、参数、字典键或变量。仅当目标在 5 个及以上文件中出现、每个文件重命名逻辑相同、且文件之间互不影响时使用。少于 5 个文件用顺序编辑更简单；跨文件级联重构、需要上下文判断的改名、复杂 AST 变换不适合本技能，后者可使用 libcst-refactor agent。
主要能力：用 haiku 模型驱动的多个 Task 智能体并行处理文件，每个文件一个智能体，避免跨文件编辑冲突，单点失败可单独重试；通过分波执行处理依赖关系。
使用方式：
- 用 Grep 找出所有含目标标识符的文件：Grep(pattern="old_name", output_mode="files_with_matches")，并分为源码文件与测试文件。
- 第一波并行启动源码文件智能体，每个文件或每 2-3 个相关文件一个 Task，例如：Task(subagent_type='general-purpose', model='haiku', description='Rename old_name in path/to/file.py', prompt="""...""")。所有源码智能体应在同一条消息中启动以并发执行。
- 等待源码智能体完成并检查错误。
- 第二波再并行启动测试文件智能体，因为测试依赖源码。
- 全部完成后验证：用 Grep 确认旧名不再出现（排除有意保留的例外），并用 devrun agent 运行测试、类型检查和 lint。
每个智能体的提示应说明：在指定文件中把全部 old_name 改为 new_name，包括变量名与赋值、函数参数名、字典键定义与访问、程序性引用该标识符的字符串字面量、类型标注、按其名称引用它的注释；必须先读文件，再用 Edit 应用修改。提示必须写明边界约束，即不应改名的内容，例如用户可见消息字符串、必须保留的 GitHub API 字段、外部包导入；若无例外则明确写“No exceptions — rename ALL occurrences.”。
分批策略：第一波源码文件，第二波测试文件；波内并行，波间等待。超 30 个文件时可每组约 10-15 个智能体分批。资料中的示例显示 16 个源码文件与 12 个测试文件可在约 60 秒内完成，而顺序编辑需 10 分钟以上。
限制：需要准确划定边界，否则会过度重命名；依赖关系复杂或需要判断的改名不宜使用；缺失事实：官方文档未提供安装命令、收费信息或平台限制。