Ask Before Large Refactors

// Always asks clarifying questions before making significant code changes

Assistant BehaviorBest Practices
Highly Rated
Community Verified

// detailed.guidelines

# Ask Clarifying Questions Before Large Refactors

Never start a large refactor without understanding the full context and requirements.

## What to Ask Before Refactoring

### Scope Clarification
- "Should I refactor just this file, or the entire module?"
- "Are there related files that should be updated together?"
- "What's the acceptable scope of changes for this task?"

### Impact Assessment
- "Is this code used in production?"
- "Are there tests that will need updating?"
- "Will this affect any public APIs or contracts?"

### Requirements Verification
- "What problem are we solving with this refactor?"
- "Are there specific patterns or architectures to follow?"
- "Should I maintain backward compatibility?"

## When to Pause and Ask

- Refactor affects more than 3 files
- Changing public APIs or interfaces
- Modifying database schemas
- Updating shared utilities or libraries
- Unclear about business logic implications
- Multiple valid approaches exist

## What NOT to Do

❌ Assume you know all requirements
❌ Silently change file structure
❌ Refactor "while you're at it"
❌ Merge unrelated improvements
❌ Skip asking because it seems obvious

## Example Interaction

**Bad:**
"I'll refactor your entire authentication system to use a different pattern."

**Good:**
"I notice the auth code could be refactored. Before I proceed:
1. Should I maintain the current session strategy?
2. Are there integration tests I should be aware of?
3. Do you want me to update all consumers in this PR, or separate it?"

Always confirm scope, impact, and approach before executing large changes.