agentleFS
Sign inStart free
popsiclelmlmpopsiclelmlm/skills-cn/skills/deprecated/request-refactor-plan/SKILL.md

request-refactor-plan

Skill0 starsChanged 6 months agoMITView on GitHub

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

51 other projects use a version of this, 48 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use batch-grill-me, decision-mapping and 5 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • boyingliu01Skill

    batch-grill-me

    A relentless interview that asks every frontier question at once, round by round. Thin alias of `grilling` (#540) — upstream mattpocock/skills absorbed this protocol into grilling; XP-Gate keeps this name as the sprint-flow Phase 2 entry point so orchestration docs stay stable.

    Also in 6 projects that use this

  • FabienDehopreSkill

    decision-mapping

    Turn a loose idea into a sequenced map of investigation tickets, then drive them to resolution one at a time.

    Also in 4 projects that use this

  • HK-hubSkill

    prd-to-plan

    Turn a PRD into a multi-phase implementation plan using tracer-bullet vertical slices, saved as a local Markdown file in ./plans/. Use when user wants to break down a PRD, create an implementation plan, plan phases from a PRD, or mentions "tracer bullets".

    Also in 8 projects that use this

  • ShopifySkill

    triage-issue

    Triage a GitHub issue — classify priority (P0/P1/P2), search for duplicates, and apply labels.

    Also in 12 projects that use this

  • RoentekSkill

    loop-me

    Grill me about specs for the workflows I want to build, within this workspace.

    Also in 15 projects that use this

  • liufeng1976Skill

    setup-ts-deep-modules

    Wire dependency-cruiser into a TypeScript repo so each package is a deep module — implementation hidden in subfolders, reachable only through its entry-point files. User-invoked.

    Also in 8 projects that use this

The file

We split this skill into the rules it gives an agent

1 rule. 1 is common, 0 are distinctive, and 0 are very specific to this project.

  • 1

    Common

    Most of the 49 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Do NOT include specific file paths or code snippets.

    line 50

“Common” is measured: kept by at least 6 in 10 of the 49 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free