Request refactor plan

Skill popsiclelmlm/skills-cn/skills/deprecated/request-refactor-plan

Chinese maintenance notes and installer for practical engineering agent skills.

Install

npx -y skills add popsiclelmlm/skills-cn --skill request-refactor-plan

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

通过用户访谈创建一个包含 tiny commits 的详细 refactor plan，然后把它作为 GitHub issue 提交。当用户想规划 refactor、创建 refactoring RFC，或把 refactor 拆成安全 incremental steps 时使用。

SKILL.md

2.5 KB, as published. Nobody here has run it

当用户想创建 refactor request 时，会调用这个 skill。你应该完成下面步骤。若认为某些步骤不必要，可以跳过。

询问用户，让他们详细描述想解决的问题以及任何潜在 solution ideas。
探索 repo，验证他们的 assertions 并理解 codebase 当前状态。
询问他们是否考虑过其他 options，并向他们展示其他 options。
围绕 implementation 采访用户。要极其详细和彻底。
敲定 implementation 的确切 scope。弄清你计划改变什么，以及计划不改变什么。
查看 codebase，检查该区域是否有 test coverage。如果 test coverage 不足，询问用户的 testing plans。
把 implementation 拆成 tiny commits 的 plan。记住 Martin Fowler 的建议： "make each refactoring step as small as possible, so that you can always see the program working."
用 refactor plan 创建 GitHub issue。Issue description 使用以下 template：

<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.

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>

Gives 0 of the 12 instructions most plan spec skills give

Counted across 1,100 of the 1,860 authors here whose files we hold, read 2026-08-06

ask one question at a timein 46 of 1100, across 38 files
Break plans into vertical slicesin 28 of 1100, across 10 files
Publish issues in dependency orderin 27 of 1100, across 9 files
Iterate until user approves the breakdownin 24 of 1100, across 6 files
Explore the repository to understand the codebase statein 24 of 1100, across 7 files
Use domain glossary vocabularyin 23 of 1100, across 5 files
Apply correct triage labels to published issuesin 23 of 1100, across 5 files
Write failing tests before implementation codein 23 of 1100, across 18 files
Prefer AFK slices over HITLin 22 of 1100, across 7 files
ask clarifying questions until requirements are concretein 21 of 1100, across 13 files
Respect existing architecture decision recordsin 20 of 1100, across 5 files
write a specification before writing any codein 20 of 1100, across 12 files

Said here and by no other author read

finalize the exact scope of changes
ask the user about testing plans if coverage is lacking

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.