Optimizing Cline with Custom Instructions for Complex React Component Refactoring

Cline is a beast for autonomous coding, but if you leave the system prompt as-is, it tends to "over-engineer" simple refactors or, worse, hallucinate hooks that don't exist in your specific project version. I spent the last month fighting with it while refactoring a massive legacy dashboard full of prop-drilling and monolithic components. The breakthrough happened when I stopped treating Cline like a chat bot and started treating it like a junior dev who needs a strict style guide.

The secret is the .clinerules file (or the custom instructions block). If you don't explicitly define your architectural constraints, Cline will often suggest adding new libraries or changing your state management pattern just because it's "cleaner" in a generic sense, which creates a nightmare for PR reviews.

For complex React refactoring, I found that forcing a "Plan-then-Execute" loop in the instructions reduces bugs by about 40%. Instead of letting it just start rewriting files, I tell it to output a technical design doc first.

Here is the specific instruction block I added to my custom rules to handle React component splits:

When refactoring React components:
1. Analysis Phase: Map out all state dependencies and props. Identify "pure" UI logic vs. "side-effect" logic.
2. Extraction Strategy: Create a separate file for logic (custom hooks) and a separate file for the presentational component.
3. Constraint: Do not introduce new dependencies unless explicitly asked. 
4. Type Safety: Every new component must have an interface for Props; avoid 'any' at all costs.
5. Verification: After refactoring, you must check the original file to ensure no logic was dropped during the move.

One major "gotcha" I hit was with Tailwind CSS. Cline loves to "optimize" classes by grouping them, but it often messes up the responsive breakpoints or removes conditional classes that were critical for state changes. To fix this, I added a rule: Never modify existing Tailwind classes unless the visual layout is explicitly being changed.

My current workflow for a complex refactor looks like this:

Step 1: The Audit
I highlight the messy component and prompt:
@file:Dashboard.tsx Analyze the state flow and list every hook being used. Tell me which parts can be extracted into a useDashboardLogic hook.

Step 2: The Blueprint
Once it lists the dependencies, I command:
Create a implementation plan. Define the API for the new hook and the props for the new sub-components. Do not write the code yet.

Step 3: The Execution
Only after I approve the plan do I say:
Execute the plan. Start with the hook, then the sub-components, and finally update the main file.

This prevents the "hallucination spiral" where the AI changes a variable name in one file and forgets to update it in the other, leading to a cascade of TypeScript errors that take 20 minutes to debug.

Productivity-wise, this shift from "Do this" to "Plan this, then do this" has cut my refactoring time significantly. I'm no longer spending half my time reverting "improvements" that broke the build. If you're using Cline for anything larger than a single-file utility, stop relying on the default prompt—your project's specific patterns are the only thing that keep the AI from drifting into generic territory.