Back to Details

request-refactor-plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
This skill will be invoked when the user wants to create a refactor request. You should go through the steps below. You may skip steps if you don't consider them necessary.
  1. Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions.
  2. Explore the repo to verify their assertions and understand the current state of the codebase.
  3. Ask whether they have considered other options, and present other options to them.
  4. Interview the user about the implementation. Be extremely detailed and thorough.
  5. Hammer out the exact scope of the implementation. Work out what you plan to change and what you plan not to change.
  6. Look in the codebase to check for test coverage of this area of the codebase. If there is insufficient test coverage, ask the user what their plans for testing are.
  7. Break the implementation into a plan of tiny commits. Remember Martin Fowler's advice to "make each refactoring step as small as possible, so that you can always see the program working."
  8. Create a GitHub issue with the refactor plan. Use the following template for the issue description:
<refactor-plan-template>
当用户想要创建重构请求时，将调用此Skill。请按照以下步骤操作，若认为某些步骤不必要可跳过。
  1. 请求用户提供他们想要解决的问题的详细描述，以及任何潜在的解决方案思路。
  2. 查看代码仓库（repo）以验证他们的表述，并了解代码库的当前状态。
  3. 询问用户是否考虑过其他方案，并向他们介绍其他可选方案。
  4. 就实现细节对用户进行访谈，访谈需极其详尽全面。
  5. 明确界定实现的确切范围，确定计划修改和不修改的内容。
  6. 检查代码库中该区域的测试覆盖率（test coverage）。如果测试覆盖率不足，询问用户的测试计划。
  7. 将拆分为包含微小提交的计划。记住Martin Fowler的建议：“让每个重构步骤尽可能小，这样你总能看到程序正常运行。”
  8. 使用重构计划创建GitHub Issue。请使用以下模板作为Issue描述：
<refactor-plan-template>

Problem Statement

问题陈述

The problem that the developer is facing, from the developer's perspective.
从开发者视角描述其面临的问题。

Solution

解决方案

The solution to the problem, from the developer's perspective.
从开发者视角描述问题的解决方案。

Commits

提交记录

A LONG, detailed implementation plan. Write the plan in plain English, breaking down the implementation into the tiniest commits possible. Each commit should leave the codebase in a working state.
一份详尽的实现计划。用通俗易懂的语言撰写，将拆分为尽可能小的提交。每个提交都应确保代码库处于可运行状态。

Decision Document

决策文档

A list of implementation decisions that were made. This can include:
  • The modules that will be built/modified
  • The interfaces of those modules that will be modified
  • Technical clarifications from the developer
  • Architectural decisions
  • Schema changes
  • API contracts
  • Specific interactions
Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
列出已做出的实现决策，可包括：
  • 将构建/修改的模块
  • 将修改的模块接口
  • 来自开发者的技术说明
  • 架构决策
  • 模式变更
  • API契约
  • 特定交互
请勿包含具体文件路径或代码片段，这些内容可能很快过时。

Testing Decisions

测试决策

A list of testing decisions that were made. Include:
  • A description of what makes a good test (only test external behavior, not implementation details)
  • Which modules will be tested
  • Prior art for the tests (i.e. similar types of tests in the codebase)
列出已做出的测试决策，包括：
  • 描述优质测试的标准（仅测试外部行为，而非实现细节）
  • 将进行测试的模块
  • 测试的参考范例（即代码库中类似类型的测试）

Out of Scope

范围外内容

A description of the things that are out of scope for this refactor.
描述本次重构不涉及的内容。

Further Notes (optional)

补充说明（可选）

Any further notes about the refactor.
</refactor-plan-template>
关于重构的其他说明。
</refactor-plan-template>