mirror of
https://github.com/MLSysBook/TinyTorch.git
synced 2026-03-12 04:43:55 -05:00
Add shared AI assistant rules for all tools
Create comprehensive guidelines for git commits, code quality, testing, and development workflow that apply to Cursor, Claude, and any other AI assistants
This commit is contained in:
147
.shared-ai-rules.md
Normal file
147
.shared-ai-rules.md
Normal file
@@ -0,0 +1,147 @@
|
||||
# Shared AI Assistant Rules
|
||||
|
||||
**These rules apply to ALL AI assistants working on this project (Cursor, Claude, GitHub Copilot, etc.)**
|
||||
|
||||
## Git Commit Guidelines
|
||||
|
||||
### Commit Structure
|
||||
- **Make small, focused commits** - one logical change per commit
|
||||
- **Never lump multiple unrelated changes** into a single commit
|
||||
- Each module fix should be its own commit
|
||||
- Each feature should be its own commit
|
||||
- Each bug fix should be its own commit
|
||||
|
||||
### Commit Message Format
|
||||
```
|
||||
<type>: <short summary>
|
||||
|
||||
<optional detailed description>
|
||||
```
|
||||
|
||||
**Types:**
|
||||
- `fix`: Bug fixes
|
||||
- `feat`: New features
|
||||
- `refactor`: Code restructuring
|
||||
- `docs`: Documentation changes
|
||||
- `test`: Test additions or fixes
|
||||
- `chore`: Maintenance tasks
|
||||
|
||||
**Rules:**
|
||||
- **Never use exclamation marks** in commit messages
|
||||
- Keep first line under 72 characters
|
||||
- Use imperative mood: "Fix bug" not "Fixed bug"
|
||||
- Be specific and descriptive
|
||||
- Reference issue numbers when applicable
|
||||
|
||||
**Good Examples:**
|
||||
```
|
||||
Fix Module 06 optimizers AdamW gradient handling
|
||||
Add KV cache support for transformer inference
|
||||
Refactor attention masking to use standard conventions
|
||||
```
|
||||
|
||||
**Bad Examples:**
|
||||
```
|
||||
Fix stuff!
|
||||
Update files
|
||||
Changes
|
||||
WIP
|
||||
```
|
||||
|
||||
### What NOT to Commit
|
||||
- Generated files (`.ipynb` notebooks - they're auto-generated from `.py`)
|
||||
- `__pycache__/` directories
|
||||
- Build artifacts
|
||||
- Temporary files
|
||||
- IDE-specific configuration (`.vscode/`, `.idea/`)
|
||||
- AI assistant folders (`.cursor/`, `.claude/`, `.ai/`)
|
||||
|
||||
## Code Quality
|
||||
|
||||
### Critical Rules
|
||||
- **Test every change** before moving to the next task
|
||||
- **Run inline tests** immediately after defining them
|
||||
- **Never skip testing** - it catches issues early
|
||||
- **Check imports** - ensure all dependencies are available
|
||||
|
||||
### Development Workflow
|
||||
1. Make a change
|
||||
2. Test the change
|
||||
3. Verify it works
|
||||
4. Commit (small, focused commit)
|
||||
5. Move to next change
|
||||
|
||||
**Never:**
|
||||
- Make multiple changes without testing
|
||||
- Commit untested code
|
||||
- Bundle unrelated changes together
|
||||
|
||||
## TinyTorch-Specific Rules
|
||||
|
||||
### Module Development
|
||||
- All source code lives in `modules/source/XX_name/name_dev.py`
|
||||
- `.ipynb` files are generated - don't edit them directly
|
||||
- Use `tito export` to sync changes to the package
|
||||
- Test with `tito test <module_name>`
|
||||
|
||||
### Testing Philosophy
|
||||
- **Inline tests** = component validation within modules
|
||||
- **`tests/` directory** = integration tests across modules
|
||||
- Every module must have passing inline tests
|
||||
- Integration tests verify modules work together
|
||||
|
||||
### Code Organization
|
||||
- Avoid duplication - create shared utilities
|
||||
- Follow existing module structure
|
||||
- Maintain consistent formatting
|
||||
- Use the project's established patterns
|
||||
|
||||
## Communication
|
||||
|
||||
### With the User
|
||||
- Be direct and concise
|
||||
- Don't ask for permission for standard operations
|
||||
- Propose solutions, don't just describe problems
|
||||
- Show progress with concrete results
|
||||
|
||||
### In Code
|
||||
- Write clear, educational comments
|
||||
- Explain non-obvious decisions
|
||||
- Document complex algorithms
|
||||
- Use meaningful variable names
|
||||
|
||||
## Efficiency
|
||||
|
||||
### Tool Usage
|
||||
- Use specialized tools over terminal commands when available
|
||||
- Make parallel tool calls when operations are independent
|
||||
- Read multiple files simultaneously when needed
|
||||
- Batch related operations
|
||||
|
||||
### Problem Solving
|
||||
- **Be proactive** - fix issues when you find them
|
||||
- **Think critically** - challenge assumptions
|
||||
- **Consider edge cases** - don't just test happy paths
|
||||
- **Learn from errors** - patterns repeat
|
||||
|
||||
## Quality Standards
|
||||
|
||||
### Before Committing
|
||||
- [ ] All tests pass
|
||||
- [ ] No linter errors
|
||||
- [ ] Imports are correct
|
||||
- [ ] Code follows project style
|
||||
- [ ] Commit message is clear and specific
|
||||
- [ ] Only changed files are included
|
||||
|
||||
### Before Marking Complete
|
||||
- [ ] Feature works as intended
|
||||
- [ ] Edge cases are handled
|
||||
- [ ] Documentation is updated
|
||||
- [ ] Tests are passing
|
||||
- [ ] No regressions introduced
|
||||
|
||||
---
|
||||
|
||||
**Remember:** Quality over speed. Small, tested, well-documented commits are better than large, untested, rushed ones.
|
||||
|
||||
Reference in New Issue
Block a user