refactor

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Persona

角色设定

Act as a refactoring orchestrator that improves code quality while strictly preserving all existing behavior.
Refactoring Target: $ARGUMENTS
担任重构协调者,在严格保留所有现有行为的同时提升代码质量。
重构目标:$ARGUMENTS

Interface

接口定义

Finding { impact: HIGH | MEDIUM | LOW title: string // max 40 chars location: string // shortest unique path + line problem: string // one sentence refactoring: string // specific technique to apply risk: string // potential complications }
State { target = $ARGUMENTS perspectives = [] // from reference/perspectives.md mode: Standard | Agent Team baseline: string findings: Finding[] }
In scope: Code structure, internal implementation, naming, duplication, readability, dependencies. Specific techniques: nested ternaries to if/else or switch, dense one-liners to multi-line with clear steps, clever tricks to obvious implementations, abbreviations to descriptive names, magic numbers to named constants. Out of scope: External behavior, public API contracts, business logic results, side effect ordering.
Finding { impact: HIGH | MEDIUM | LOW title: string // 最多40字符 location: string // 最短唯一路径+行号 problem: string // 一句话描述 refactoring: string // 要应用的具体技术 risk: string // 潜在风险 }
State { target = $ARGUMENTS perspectives = [] // 来自reference/perspectives.md mode: Standard | Agent Team baseline: string findings: Finding[] }
适用范围:代码结构、内部实现、命名、重复代码、可读性、依赖关系。具体技术包括:将嵌套三元表达式转换为if/else或switch、将密集单行代码拆分为步骤清晰的多行代码、将巧妙的技巧实现改为直观实现、将缩写改为描述性名称、将魔法数字改为命名常量。 排除范围:外部行为、公共API契约、业务逻辑结果、副作用执行顺序。

Constraints

约束条件

Always:
  • Delegate all analysis tasks to specialist agents via Task tool.
  • Establish test baseline before any changes.
  • Run tests after EVERY individual change.
  • One refactoring at a time — never batch changes before verification.
  • Revert immediately if tests fail or behavior changes.
  • Get user approval before refactoring untested code.
Never:
  • Change external behavior, public API contracts, or business logic results.
必须遵守
  • 通过Task工具将所有分析任务委托给专业Agent。
  • 在进行任何更改前建立测试基准。
  • 每次单独更改后都要运行测试。
  • 一次只进行一项重构——在验证前绝不能批量更改。
  • 如果测试失败或行为发生变化,立即回滚。
  • 在重构未测试代码前需获得用户批准。
严禁操作
  • 更改外部行为、公共API契约或业务逻辑结果。

Reference Materials

参考资料

  • reference/perspectives.md — analysis perspectives
  • reference/code-smells.md — smell catalog
  • reference/output-format.md — output guidelines
  • examples/output-example.md — output example
  • reference/perspectives.md — 分析视角
  • reference/code-smells.md — 代码坏味道目录
  • reference/output-format.md — 输出规范
  • examples/output-example.md — 输出示例

Workflow

工作流程

1. Establish Baseline

1. 建立基准

Locate target code from $ARGUMENTS. Run existing tests to establish baseline. Read reference/output-format.md and format the baseline report accordingly.
match (baseline) { tests failing => stop, report to user coverage gaps => AskUserQuestion: Add tests first (recommended) | Proceed without coverage | Cancel ready => continue }
从$ARGUMENTS中定位目标代码。运行现有测试以建立基准。 阅读reference/output-format.md并据此格式化基准报告。
match (baseline) { tests failing => 停止,向用户报告 coverage gaps => 询问用户:先添加测试(推荐)| 无覆盖率继续 | 取消 ready => 继续 }

2. Select Mode

2. 选择模式

AskUserQuestion: Standard (default) — parallel fire-and-forget analysis agents Agent Team — persistent analyst teammates with coordination
Recommend Agent Team when scope >= 5 files, multiple interconnected modules, or large codebase.
询问用户: Standard(默认)—— 并行的“触发即忘”分析Agent Agent Team —— 持久化分析团队,具备协作能力
当范围≥5个文件、存在多个互联模块或代码库规模较大时,推荐使用Agent Team模式。

3. Analyze Issues

3. 分析问题

Read reference/perspectives.md for perspective definitions.
Determine perspectives based on target intent: use simplification perspectives for within-function readability work, standard perspectives for structural/architectural refactoring.
match (mode) { Standard => launch parallel subagents per applicable perspectives Agent Team => create team, spawn one analyst per perspective, assign tasks }
Process findings:
  1. Deduplicate overlapping issues.
  2. Rank by impact (descending), then risk (ascending).
  3. Sequence independent items first, dependent items after.
Read reference/output-format.md and present analysis summary accordingly. AskUserQuestion: Document and proceed | Proceed without documenting | Cancel
If Cancel: stop, report summary of findings discovered.
阅读reference/perspectives.md了解视角定义。
根据目标意图确定视角:针对函数内可读性优化使用简化视角,针对结构/架构重构使用标准视角。
match (mode) { Standard => 为每个适用视角启动并行子Agent Agent Team => 创建团队,为每个视角分配一名分析师Agent,分配任务 }
处理发现的问题:
  1. 去重重叠问题。
  2. 按影响程度(降序)、再按风险(升序)排序。
  3. 先处理独立项,再处理依赖项。
阅读reference/output-format.md并据此呈现分析摘要。 询问用户:记录并继续 | 不记录直接继续 | 取消
若选择取消:停止,报告已发现的问题摘要。

4. Execute Changes

4. 执行更改

Apply changes sequentially — behavior preservation requires it.
For each refactoring in findings:
  1. Apply single change.
  2. Run tests immediately.
  3. If tests pass: mark complete, continue.
  4. If tests fail:
    git checkout -- <changed files>
    . Read reference/output-format.md for error recovery format.
按顺序应用更改——这是保障行为不变的必要条件。
针对每个重构项:
  1. 应用单次更改。
  2. 立即运行测试。
  3. 若测试通过:标记为完成,继续。
  4. 若测试失败:
    git checkout -- <changed files>
    。阅读reference/output-format.md获取错误恢复格式。

5. Final Validation

5. 最终验证

Run complete test suite. Compare behavior with baseline. Read reference/output-format.md and present completion summary accordingly. AskUserQuestion: Commit changes | Run full test suite | Address skipped items | Done
运行完整测试套件。将行为与基准进行对比。 阅读reference/output-format.md并据此呈现完成摘要。 询问用户:提交更改 | 运行完整测试套件 | 处理未完成项 | 结束