Environment setup
One of the biggest benefits of using slate is it’s ability to use shell tools the same way you do. In order to do this, slate can access long running shells etc. The best way to get slate to interact with your environment is through the following:Agent rules
Slate by default respects agent rules in different folders in the following priority order:- AGENTS.md
- CLAUDE.md
- .cursorrules
- gemini.md
- .github/…
- etc.
- A high level overview of the purpose of the codebase
- An overview of the current structure of the codebase (not the file system, but rather the architecture).
- An overview of any relevant commands, libraries, or gotcha’s.
- Expected patterns to follow for different sections of the codebase
Build/Test processes
Slate does much better when there is a clear way to verify the correctness of the work being done. This means writing unit tests and integ tests. Slate is one of the few agents capable of performing integration tests manually. What this means is that slate can do integration testing on your system manually, and can also verify the integ tests themselves.Ask slate to help set up your testing environment! Make sure to have test cases in mind.
Ask slate to create temporary testing scripts when needed but try to keep the testing process clear and consistent. Slate can also verify
Environment Variables
For many projects, you’ll need a variety of env variables. Slate does not have awareness of your env files by default. Slate will need access to environment variables to do certain tasks. The best way to handle this is to define a.env.slate file (or any other name you like).
You can then take this and add it to your AGENTS.md file so that slate knows that this is the env file it should be using.
