git_refactor_skill_skill

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.