Advanced Features: becoming a Power User 🧠

Usage 📖

Mention important files

To ensure that Sweep scans a file, mention the file name in your ticket. Sweep searches for relevant files at runtime, but specifying the file helps avoid missing important details.

Giving Sweep feedback

If Sweep's plan isn't accurate, you can respond to Sweep in three places:

1. Issue: Sweep will create a new pull request and close the old one. Alternatively, you can edit the issue description to recreate the pull request.
2. Pull request: Sweep will update the PR based on your PR comments
3. Code: Sweep will only update the file that the comment is on

Whenever you make a message that Sweep is taking a look at, you will see an 👀 emoji. If you don't see this, make sure the PR/issue is open and you prefixed the message with "sweep:".

Further, on failed Github Action runs, Sweep will update the PR based on the error message.

Switch branch

To get Sweep to use a different base branch for one issue, add the following to the issue description.

branch: BRANCH_NAME

Configuration 🛠️

Use GitHub Actions

We highly recommend linters, as well as Netlify/Vercel preview builds. Sweep auto-corrects based on linter and build errors, and Netlify and Vercel helps with iteration cycles by providing previews of static sites using Netlify.

Set up sweep.yaml

You can set up sweep.yaml to

• Provide up to date docs by setting up docs (https://docs.sweep.dev/usage/config#docs (opens in a new tab))
• Set up automated formatting and linting by setting up sandbox (https://docs.sweep.dev/usage/config#sandbox (opens in a new tab)). Never have Sweep commit a failing npm lint again.
• Give Sweep a high level description of where to find files in your repo by editing the repo_description field.

For more on configs, check out https://docs.sweep.dev/usage/config (opens in a new tab).

Prompting 🗣️

The amount of prompting you need to give Sweep directly scales with the complexity of the problem.

For harder problems, try to provide the same information a human would need, and for simpler problems, providing a single line and a file name should suffice.

Prompting formats

A good issue should include where to look (file name or entity name), what to do ("change the logic to do this"), and additional context (there's a bug/we need this feature/there's this dependency). Examples:

• In sweepai/app/ui.py, use an os-agnostic temp directory.
• In on_comment.py, we should not fire an event because it's possible that the comment is on a closed PR.
• In the config loader in packages/server/src/config.ts, add a third option called "env" to load the config settings from environment variables. At present, there are two options: 1. ... and 2. ...

Show by example

Provide similar files for Sweep to look at, like "Write a unit test for src/Menu.tsx like src/Navbar.test.tsx". This is effective because the problem boils down to a translation task, and allows Sweep to very quickly learn by example without manually writing a lot of detail.

Use an imperative tone when writing comments

This means writing the comment as a command or instruction. For example, instead of writing 'This line of code needs to be optimized', write 'Optimize this line of code'. Using an imperative tone makes the action required clear and direct.

Be specific

Don’t write “fix typos”, "write tests" or “optimize the SEO”. Sweep will get confused and will crash. Put a real issue that you would like solved in your codebase, with as much detail as you would provide a junior developer.

In general, you should know about what the solution would look like before you ask Sweep to solve it.

Limitations 🚫

Sweep is unlikely to complete complex issues on the first try, similar to the average junior developer. Here are Sweep's limitations(for now):

• Try to change less than 300 lines of code
• Try to modify less than 5 files