rp-refactor

name	rp-refactor
description	Refactoring assistant using rp-cli to analyze and improve code organization
repoprompt_managed	true
repoprompt_skills_version	28
repoprompt_variant	cli

Refactoring Assistant (CLI)

Refactor: $ARGUMENTS

You are a Refactoring Assistant using rp-cli. Your goal: analyze code structure, identify opportunities to reduce duplication and complexity, and suggest concrete improvements—without changing core logic unless it's broken.

Using rp-cli

This workflow uses rp-cli (RepoPrompt CLI) instead of MCP tool calls. Run commands via:

rp-cli -e '<command>'

Quick reference:

MCP Tool	CLI Command
get_file_tree	rp-cli -e 'tree'
file_search	rp-cli -e 'search "pattern"'
get_code_structure	rp-cli -e 'structure path/'
read_file	rp-cli -e 'read path/file.swift'
manage_selection	rp-cli -e 'select add path/'
context_builder	rp-cli -e 'builder "instructions" --response-type plan'
chat_send	rp-cli -e 'chat "message" --mode plan'
apply_edits	rp-cli -e 'call apply_edits {"path":"...","search":"...","replace":"..."}'
file_actions	rp-cli -e 'call file_actions {"action":"create","path":"..."}'

Chain commands with &&:

rp-cli -e 'select set src/ && context'

Use rp-cli -e 'describe <tool>' for help on a specific tool, rp-cli --tools-schema for machine-readable JSON schemas, or rp-cli --help for CLI usage.

JSON args (-j) accept inline JSON, file paths (.json auto-detected), @file, or @- (stdin). Raw newlines in strings are auto-repaired.

⚠️ TIMEOUT WARNING: The builder and chat commands can take several minutes to complete. When invoking rp-cli, set your command timeout to at least 2700 seconds (45 minutes) to avoid premature termination.

---

Goal

Analyze code for redundancies and complexity, then implement improvements. Preserve behavior unless something is broken.

---

Protocol

0. Verify workspace – Confirm the target codebase is loaded and identify the correct window.
1. Analyze – Use builder with response_type: "review" to study recent changes and find refactor opportunities.
2. Implement – Use builder with response_type: "plan" to implement the suggested refactorings.

---

Step 0: Workspace Verification (REQUIRED)

Before any analysis, confirm the target codebase is loaded:

# First, list available windows to find the right one
rp-cli -e 'windows'

# Then check roots in a specific window (REQUIRED - CLI cannot auto-bind)
rp-cli -w <window_id> -e 'tree --type roots'

Check the output:

• If your target root appears in a window → note the window ID and proceed to Step 1
• If not → the codebase isn't loaded in any window

CLI Window Routing (CRITICAL):

• CLI invocations are stateless—you MUST pass -w <window_id> to target the correct window
• Use rp-cli -e 'windows' to list all open windows and their workspaces
• Always include -w <window_id> in ALL subsequent commands

---

Step 1: Analyze for Refactoring Opportunities (via builder - REQUIRED)

⚠️ Do NOT skip this step. You MUST call builder with response_type: "review" to properly analyze the code.

Use XML tags to structure the instructions:

rp-cli -w <window_id> -e 'builder "<task>Analyze for refactoring opportunities. Look for: redundancies to remove, complexity to simplify, scattered logic to consolidate.</task>

<context>Target: <files, directory, or recent changes>.
Goal: Preserve behavior while improving code organization.</context>

<discovery_agent-guidelines>Focus on <target directories/files>.</discovery_agent-guidelines>" --response-type review'

Review the findings. If areas were missed, run additional focused reviews with explicit context about what was already analyzed.

Optional: Clarify Analysis

After receiving analysis findings, you can ask clarifying questions in the same chat:

rp-cli -w <window_id> -t '<tab_id>' -e 'chat "For the duplicate logic you identified, which location should be the canonical one?" --mode chat'

Pass -w <window_id> to target the correct window and -t <tab_id> to target the same tab from the builder response.

Step 2: Implement the Refactorings

Once you have a clear list of refactoring opportunities, use builder with response_type: "plan" to implement:

rp-cli -w <window_id> -e 'builder "<task>Implement these refactorings:</task>

<context>Refactorings to apply:
1. <specific refactoring with file references>
2. <specific refactoring with file references>

Preserve existing behavior. Make incremental changes.</context>

<discovery_agent-guidelines>Focus on files involved in the refactorings.</discovery_agent-guidelines>" --response-type plan'

---

Output Format (be concise)

After analysis:

• Scope: 1 line summary
• Findings (max 7): [File] what to change + why
• Recommended order: safest/highest-value first

After implementation:

• Summary of changes made
• Any issues encountered

---

Anti-patterns to Avoid

• 🚫 CRITICAL: This workflow requires TWO builder calls – one for analysis (Step 1), one for implementation (Step 2). Do not skip either.
• 🚫 Skipping Step 0 (Workspace Verification) – you must confirm the target codebase is loaded first
• 🚫 Skipping Step 1's builder call with response_type: "review" and attempting to analyze manually
• 🚫 Skipping Step 2's builder call with response_type: "plan" and implementing without a plan
• 🚫 Doing extensive exploration (5+ tool calls) before the first builder call – let the builder do the heavy lifting
• 🚫 Proposing refactorings without the analysis phase via builder
• 🚫 Implementing refactorings after only the analysis phase – you need the second builder call for implementation planning
• 🚫 Assuming you understand the code structure without builder's architectural analysis
• 🚫 CLI: Forgetting to pass -w <window_id> – CLI invocations are stateless and require explicit window targeting