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. 检查代码库中该区域的测试覆盖率。如果测试覆盖率不足，询问用户的测试计划。
  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>