home / skills / theonelee / theone_claude_skill / git_refactor_skill

git_refactor_skill skill

safe

This skill analyzes git differences from a starting commit to HEAD and refactors code into cohesive, maintainable structures according to user commands.

npx playbooks add skill theonelee/theone_claude_skill --skill git_refactor_skill

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

1.8 KB

---
name: git_refactor_skill
description: 分析 git commit 差异并根据用户指令进行重构的技能。它可以根据指定的 commit 到 HEAD 之间的变更，以最强大脑视角提供高内聚、易维护的重构建议。
---

# Git Refactor Skill

这个技能旨在通过分析特定的 Git commit 到 HEAD 之间的代码变更，结合用户提供的具体指令（`<command>`），执行高质量的代码重构。

## 核心任务

1. **确认输入**：与用户确认 `<git_commit>`（要分析的起始 commit ID）和 `<command>`（具体的重构要求，如提取工具类、规范度量上报等）。
2. **变更分析**：使用 `git diff <git_commit> HEAD` 分析受影响的文件和具体变更内容。
3. **重构实施**：以“最强大脑”的视角，对变更涉及的代码进行重构，目标是：
   - **高内聚**：相关的逻辑应该放在一起。
   - **易于调用**：上层接口应简洁明了。
   - **高可读性与可维护性**：代码结构清晰，易于理解和后续修改。
4. **满足特定要求**：确保重构方案符合 `<command>` 中的具体指导，例如：
   - 将相关函数（如上报、数据处理）封装到独立的类及方法中。
   - 确保重构后的代码易于移植到其他项目。


## 使用示例

用户输入：
- `<git_commit>`: `973a21b1`
- `<command>`: "把 metric 上报、tags 存储到 `flask.g` 的逻辑封装到一个单独的类中，方便移植和调用。"

执行流程：
1. 检视从 `973a21b1` 到当前 HEAD 的所有改动。
2. 识别出所有硬编码或散乱的 metric/tags 处理逻辑。
3. 创建新的工具类，并将这些逻辑迁移至该类的方法中。
4. 更新业务代码以调用新创建的工具类。
5. 验证变更并运行测试。

Overview

This skill analyzes git commit diffs from a specified commit to HEAD and produces targeted refactoring suggestions or code edits based on the user’s instructions. It focuses on producing high-cohesion, easy-to-call, and maintainable refactor outcomes that are ready to integrate. The skill aims to turn scattered or hard-coded logic into well-encapsulated components that are easy to reuse and test.

How this skill works

You provide a starting git commit ID and a clear refactoring command. The skill runs a diff for the range, inspects affected files and changed code patterns, and identifies candidate functions, classes, and duplicated logic. It then proposes concrete refactor steps or generates replacement code that follows the instructed design (for example, extracting helpers into a new class, standardizing metric reporting, or centralizing tag storage).

When to use it

You want to consolidate scattered logic introduced between a past commit and the current HEAD.
You need to extract and encapsulate cross-cutting concerns (metrics, logging, tags) into reusable components.
You want automated, review-ready refactor suggestions tied to specific changesets.
You need to make code portable across projects by isolating project-specific state handling.
You want to reduce duplication and improve maintainability after a sequence of commits.

Best practices

Provide a precise <git_commit> and a concise <command> that states desired outcomes and constraints.
Focus commands on single responsibilities (e.g., extract metrics reporter, centralize tags) for clearer changes.
Run tests and static analysis after applying proposed refactors to catch integration issues early.
Prefer small, incremental refactors per diff to simplify review and rollback if needed.
Specify portability and API expectations (constructor args, lifecycle) when requesting extraction for reuse.

Example use cases

Extract metric reporting and tag storage scattered across request handlers into a single MetricsClient class for reuse and portability.
Refactor ad-hoc data processing functions introduced across multiple commits into a cohesive utility module with clear public API.
Centralize feature-flag checks and decision logic into a PolicyManager to simplify callers and unit tests.
Wrap framework-specific state (e.g., flask.g) into an adapter class so business code no longer depends on framework globals.
Convert repeated inline validation code into a shared validator class with consistent error handling and logging.

FAQ

What inputs do you need to perform the refactor?

I need a starting git commit ID and a clear refactoring command describing the desired extraction, encapsulation, or API shape.

Will the skill modify files directly?

I can produce concrete patch suggestions or replacement code; apply changes manually or via your preferred tooling after review and testing.