Rules File Writer

Analyze this project and write a {{rules_format}} file ({{file_name}}).

Scan the project and detect:
1. **Language & framework**: Versions, key dependencies
2. **Code style**: Indentation, quotes, semicolons, trailing commas (check .eslintrc, .prettierrc, or infer from code)
3. **Naming conventions**: Files (kebab-case, PascalCase?), functions, components, constants, types
4. **Import patterns**: Ordering, path aliases, barrel exports
5. **Component patterns**: Functional vs class, prop drilling vs context, state management library
6. **Testing patterns**: Framework, file naming (*.test.ts vs *.spec.ts), assertion style
7. **Project structure**: Where things live and the rationale

Write the rules file with:
- Project overview section
- Tech stack summary
- Specific do's and don'ts based on actual patterns found
- File structure guide
- Common commands (dev, build, test, lint, deploy)
- Example code snippets showing the "right way" for this project

Make every rule specific and evidence-based. Instead of "use descriptive names," say "use camelCase for functions, PascalCase for components, SCREAMING_SNAKE for constants" — based on what you actually found in the code.