generate_refactoring_code

get_health(include=["refactoring"]) returns ranked, structured refactoring plans, not template strings. generate_refactoring_code takes one plan's id and turns it into actual generated code: for Extract Class, the result includes an LCOM4 before/after self-check. The plans come from Refactoring intelligence; the rest of the tool surface is on MCP tools.

Turning it on#

This is an opt-in tool: it is not registered by default in any mode. Turn it on per repo:

# .repowise/config.yaml
mcp:
  tools: ["+generate_refactoring_code"]

Code generation itself is on unless the repo turns it off with refactoring.llm.enabled: false. Then the call still returns the plan, with generation: {available: false, reason: "disabled"}.

When enabled, it uses the repo's configured LLM provider/model (bring your own key) and caches results by a content hash, so an unchanged plan never regenerates.

When to call#

• After get_health(include=["refactoring"]) surfaces a plan you want turned into an applyable diff.
• Only with a configured LLM provider: without one the call returns error: "no_provider". An unknown id returns error: "not_found".

Parameters#

Example#

get_health(targets=["module:src.api"], include=["refactoring"])
# -> pick a plan's `id`

generate_refactoring_code(suggestion_id="a1b2c3d4")

Things worth knowing#

• Content-hash cached. Re-running with the same plan against unchanged source returns the cached result instead of a fresh LLM call.
• Grounded, not templated. The generation is anchored on the plan's evidence plus the real source spans it references, not a generic rewrite prompt.
• Extract Class gets a self-check. The result includes an LCOM4 cohesion score before and after, so you can see whether the split actually improved cohesion.
• BYO key. Uses whichever LLM provider/model the repo already has configured for doc generation, so no separate credential.