// Always asks clarifying questions before making significant code changes
# 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.6 matches