You really don't need these for tiny one-off scripts, but they're essential for larger projects where the whole application can't fit into the LLM context at once.
Basically they're just a markdown files where you write what the project is about, where everything is located and things like that. Pretty much something you'd need to have for another human to bring them up to speed.
An example snippet from the project I just happened to have open:
## Code Structure
- All import processors go under the `cmd/` directory
- The internal/ directory contains common utility functions, use it when possible. Add to it when necessary.
- Each processor has its own subdirectory and Go package
## Implementation Requirements
- Maintain consistent Go style and idiomatic patterns
- Follow the existing architectural patterns
- Each data source processor should be implemented as a separate command
This way the LLM (Cursor in this project) knows to, for example, check the internal/ directory for common utils. And if it finds duplication, it'll automatically generate any common functions in there.
It's a way to add guidelines/rails for projects, if you don't add anything the LLM will just pick whatever. It may even change style depending on what's being implemented. In this project the Goodreads processor was 100% different from the Steam processor. A human would've seen the similarities and followed the same style, but the LLM can't do that without help.
Basically they're just a markdown files where you write what the project is about, where everything is located and things like that. Pretty much something you'd need to have for another human to bring them up to speed.
An example snippet from the project I just happened to have open:
## Code Structure
- All import processors go under the `cmd/` directory - The internal/ directory contains common utility functions, use it when possible. Add to it when necessary. - Each processor has its own subdirectory and Go package
## Implementation Requirements
- Maintain consistent Go style and idiomatic patterns - Follow the existing architectural patterns - Each data source processor should be implemented as a separate command
This way the LLM (Cursor in this project) knows to, for example, check the internal/ directory for common utils. And if it finds duplication, it'll automatically generate any common functions in there.
It's a way to add guidelines/rails for projects, if you don't add anything the LLM will just pick whatever. It may even change style depending on what's being implemented. In this project the Goodreads processor was 100% different from the Steam processor. A human would've seen the similarities and followed the same style, but the LLM can't do that without help.