Use Autohand Code to identify module seams, extract one boundary at a time, and keep imports and tests working.
Split by responsibility with tests first
Architecture Build and change Implementation Code
autohand -p "Find a safe module boundary in this file and extract it with tests"
A staged extraction plan and one validated module split.
Break a monolith into modules with Autohand Code is an architecture workflow that identifies one extraction boundary in a large file or package, moves code behind it, and keeps imports and tests working. ### At a glance | Question | Answer | | --- | --- | | Best for | large controllers, mixed utility files, and modules with multiple responsibilities | | Primary inputs | Large file, package, or responsibility to extract first; Public exports or import paths that must remain stable; Existing tests or behavior that should prove the move | | Autohand Code returns | A staged extraction plan and one validated module split. | | Avoid when | the team wants a broad redesign without a testable first extraction | ### How Autohand Code handles this workflow 1. Finds one responsibility boundary that can move without changing behavior. 2. Updates imports and exports with minimal public API churn. 3. Adds or runs focused tests around the extracted behavior. 4. Leaves a staged plan for the remaining monolith. ### Best inputs - Large file, package, or responsibility to extract first - Public exports or import paths that must remain stable - Existing tests or behavior that should prove the move ### Strong prompt autohand -p "Find a safe module boundary in this file and extract it with tests" ### Autohand Code CLI options - Run `autohand -p "Find one safe module boundary in this file and extract it with tests"` for the first split. - When `slash_goal` is enabled, use `/goal queue` for later extraction slices instead of expanding the current diff. - Use `--patch` when the team wants to review the extraction before applying it. ### Review before accepting Prefer a small extraction with passing tests and stable imports over a large reorganization that is hard to review. ### Source and validation signals Autohand AI maintains this workflow as first-party product guidance for Autohand Code. Use the [Autohand CLI Playbook](https://github.com/autohandai/code-cli/blob/main/docs/AUTOHAND_PLAYBOOK.md), [CLI reference](/docs/working-with-autohand-code/cli-reference.html), and [configuration reference](https://github.com/autohandai/code-cli/blob/main/docs/config-reference.md) when choosing between interactive mode, command mode, auto-mode, feature-enabled /goal, /settings, skills, MCP, and permission settings. The related resources below link to product docs and tutorials for the workflow, and the final answer should name repository-specific files, commands, outputs, or docs that a reviewer can verify. ### Frequently asked questions ### What is Break a monolith into modules with Autohand Code? Break a monolith into modules with Autohand Code is an architecture workflow that identifies one extraction boundary in a large file or package, moves code behind it, and keeps imports and tests working. ### When should a team use Break a monolith into modules? Use it when a single validated module split would reduce risk for future work. ### What evidence should reviewers check for Break a monolith into modules? Prefer a small extraction with passing tests and stable imports over a large reorganization that is hard to review.
Tutorial Break a Monolith into Modules Extract one boundary at a time with imports and tests intact. /docs/tutorials/break-monolith-into-modules.html Guide Automated Refactoring Patterns Find module boundaries without broad churn. /docs/guides/technical-debt.html Guide Code Refactoring with Autohand Use tests and behavior contracts to keep refactors reviewable. /docs/guides/code-refactoring.html