Skip to main content
When prompting slate, you simply have to type into the input box and press enter. The input box supports the following:
  • @ mentions (@path/to/file)
  • Copy+paste
  • Esc to clear
  • Ctrl-a to jump to the beginning
  • Ctrl-e to jump to the end
  • option/alt+enter for new lines
What matters more than how you input content into the box is what you input into the box. Slate performs best when treated more autonomously than other agents. There are a few principles that will help when prompting:

​
Let slate manage it’s context

Often times, other coding agents require lots of agent rules and lots of instructions. Slate functions best when managing the exploration process on its own, and taking higher level direction from the user. This is because slate is designed to work for longer periods of time and so can manage its own context better. What should you provide slate with: The high level goal of the current session. Guidance on the order of things to do:
  • "Hey slate, research this section of my codebase @directory and then we are going to write a plan"
  • "I want you to explore X, update Y to do Z, and then update A following the same pattern"
Guidance on the general shape of the solution:
  • If there are specific files it should stick to
  • If there are specific patterns a good solution MUST have
  • What the solution should look like ex: “should we refactor or should we just add to the codebase”
  • Any specific gotchas that slate will run into during execution
Avoid prompts like the following: "Make no mistakes" "You're a really smart engineer" "ALWAYS MAKE SURE TO DO X" These prompts will generally lead to worse performance out of slate overall.

​
Clarity

The goal when prompting slate should be to be as clear and descriptive as possible. Slate is a fairly unopinionated agent and works best when describing the exact process you want it to follow and describing what you want clearly. Rather than saying: “Make a new api middleware to handle X” Say: “I need a new middleware for X and I need it on the following endpoints…”

​
Use agent rules only when necessary

Your agent rules file should ideally be sparse and contain the following information:
  • High level overview of the codebase
  • Constraints on developing in the codebase
  • Useful commands or steps to perform operations in the codebase

​
Handling long tasks

One of the key reasons to use slate is for its ability to keep working through long sessions. The best way to do this is as follows:
  1. Ask slate to research the problem first and make a plan
Hey slate, please research my codebase for <X>,
and then make a plan for implementing <Y>.
Make sure you look at @path/to/important/file
When planning with slate, it is important to make sure that slate clearly understands. Here, we want to make sure <Y> has a clear description. Slate will come back to you with a plan for how to tackle the current task.
  1. Ask slate to iterate on the provided plan
Once slate has returned with a plan, slate can ask for your opinions on the plan. Your response should be as clear and complete as possible: 
No don't do A, make sure you do it the same way B is done.
After this, slate can continue to iterate. Once you’re done, approve the plan.
  1. Executing the plan
Slate has a todo tool for managing it’s tasks. Once the plan is confirmed, slate often creates a task list for it to follow. If you are uncertain about the todos, make sure to ask slate your questions or tell slate what your concerns are. This will help slate update the plan and the todos in real time to make sure it works through the task with you. Slate will then work autonomously until a relevant stopping point is reached, likely the conclusion of the task.
For extra long tasks, somtimes slate may need a reminder about the goal after working on subsections for a long time.

​
Debugging systems with slate and background jobs

A second big benefit of using slate is the ability for slate to work well with background jobs. The best way to do this is through the following:
  1. Understand which pieces of the system need debugging
  2. Set up the env so that slate can work well in it (see Workspace setup)
  3. Prompt slate to work through the process
For best results, the following information should be present:
  • Which systems need debugging
  • Relevant stack traces
  • Context on where and how the bug occurs
  • Any relevant library information
  • Any opinions on the solution