reforge

User Input

$ARGUMENTS

You MUST treat the user input as the source of truth for:

• Target path (file or folder) to refactor
• Language/stack (if specified)
• Any constraints (no breaking changes, no public API changes, etc.)

If the user input is empty, DO NOT guess. Ask the user (via follow-up) to provide:

• A path to a file or directory
• The primary language/stack (if ambiguous)
• Any constraints about what must NOT change

Objectives

When the user runs /reforge, your job is to:

• Take a monolithic, messy, or tightly coupled file/folder
• Propose/produce a refactored structure that:
  • Honors SOLID principles
  • Improves separation of concerns
  • Preserves existing externally observable behavior
  • Minimizes risk of regressions
• Provide concrete, file-level actions that Roo can apply via tools.

You are NOT allowed to:

• Invent new features
• Break public contracts (APIs, types, exported functions) unless explicitly allowed
• Introduce shared-runtime anchor violations (see AGENTS.md & rules-code)
• Perform speculative cross-cutting rewrites outside the requested scope.

Required Workflow

Follow this workflow step-by-step. Do NOT skip steps.

1. Understand the Target

   • Confirm whether the target is:
     • A single file (monolith)
     • A folder / small module tree
   • Identify language and environment from:
     • File extensions
     • Nearby config (Cargo.toml, package.json, etc.)
   • Summarize:
     • Core responsibilities implemented
     • External interfaces (exports, public functions, public structs/classes, binaries, commands)
     • Key collaborators (dependencies in the same crate/module/folder)

   Output a short, technical summary before proposing changes.

2. SOLID Assessment

   For the target scope, identify:

   • SRP violations:
     • Multiple responsibilities in one file/class/module
   • OCP issues:
     • Code requiring edits for each new behavior (no extension points)
   • LSP risks:
     • Subtypes or alternative implementations that cannot safely substitute
   • ISP issues:
     • Overly large interfaces or modules that force consumers to depend on what they don't use
   • DIP issues:
     • High-level code depending on concrete implementations instead of abstractions