garura:refactor

Produce behavior-preserving refactor commit sequences with green test gates.

3|Updated Jan 25, 2026
One-click install
npx skills add https://github.com/kapilvirenahuja/garura --skill garura-refactor
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: garura:refactor
Source: https://github.com/kapilvirenahuja/garura/tree/main/core/components/plays/refactor
Command: npx skills add https://github.com/kapilvirenahuja/garura --skill garura-refactor

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Prevents behaviour changes while restructuring code by enforcing a green test baseline, isolation of refactor moves into atomic commits, and a final evidence report that proves what stayed the same.

Core Features & Use Cases

  • Behaviour-preserving refactor orchestration that produces a sequence of small refactor commits that keep the test suite green.
  • Automatic characterization-test safety nets for thin coverage, including a dedicated test commit phase before any refactor.
  • Blast-radius mapping and a human-approval checkpoint so you see scope impact and plan steps before execution.
  • Public API and dependency/pattern change protection, with out-of-scope work deferred to FOLLOWUPS.md.

Quick Start

Run garura:refactor for a specific target scope and restructuring goal, providing constraints, an out-of-scope list, and a time-box, so it pins the baseline with tests and generates an approval-ready refactor plan.

Frequently Asked Questions about garura:refactor

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I safely refactor code without altering observable behaviour?

You preserve observable behaviour by enforcing a green test baseline, mapping the blast radius, and isolating changes into atomic commits gated by passing tests. This sequence proves the public API and functional output remain unchanged throughout the refactor.

What are characterization tests and when do I need them for a refactor?

Characterization tests are safety nets that lock in current code behaviour before restructuring. You need them when existing test coverage is thin, ensuring your refactor commits do not accidentally alter the current observable outputs.

How do I structure atomic commits for a code restructuring workflow?

You structure atomic refactor commits by isolating each structural change into a single commit that keeps the test suite green. Pin a clean working tree baseline first, then gate every commit with passing tests to prove behaviour preservation.

How do I calculate blast radius before refactoring a module or function?

You map blast radius by analyzing the scope impact of your target restructuring goal before execution. This identifies affected dependencies and public API changes, requiring a human-approval checkpoint before any refactor commits are generated.

Can I use this refactoring approach for enterprise-grade delivery with deterministic requirements?

Yes, this refactoring approach supports deterministic, enterprise-grade delivery. It enforces a clean working tree, a green baseline with characterization tests, and a final report with an API diff to prove behaviour preservation for enterprise systems.

Why should out-of-scope work be deferred during a behaviour-preserving refactor?

Out-of-scope work must be deferred to prevent behaviour drift during refactoring. By moving non-restructuring tasks to a FOLLOWUPS.md file, you ensure atomic commits remain focused on structural changes that maintain a green test suite and an unchanged public API.