Augment official: 11 prompt word skills to create a better AI programming agent

Preface

Prompt Engineering has become a highly influential skill in modern software development. The prompts you provide to an AI agent not only determine how it plans and uses tools, but also determine whether it can build smoothly or disrupt your process. Often, only a few subtle changes - such as adding an extra context, clarifying a constraint, or adjusting the order of instructions - can bring about a significant improvement in accuracy and reliability.

This article summarizes the practical techniques we use when building autonomous AI agents at Augment Code, to help you build AI that works like a serious teammate, rather than a tool that can only "write nonsense".

The examples in this article focus on coded agents , but most of these methods are general.

What is the prompt word project?

An AI agent’s prompt includes all the inputs provided to the model. Some common components are:

• System prompt

• Tool definitions

• Tool outputs

• User instructions

• The output of the model in the previous dialogue round

Prompt engineering refers to the art of giving models better prompts to make them perform better on specific tasks. We can improve all parts of the prompt, such as:

• Add general instructions to system prompts to guide the model towards different response styles or autonomy

• Explain to the model in the tool definition when the tool should or should not be used

• Inform the model of error information or abnormal status in tool output

• Rewrite user instructions before presenting them to the model (prompt enhancement)

• Compress or truncate past model outputs to save tokens and allow more conversation history to fit into the context window. The truncation method will also affect the final quality.

What do you think of the model?

Models are (artificial) intelligent agents. Giving a model instructions is more like talking to a person than programming a computer. The model's understanding of the world is based only on what is contained in the prompts. The more complete and consistent the information you give it about the world, the better it will tend to perform.

What we see is a natural language interface, which is separate from the programming language interface we usually come into contact with. It is best to regard the interface of the language model (LM, different from our usual large language model LLM ) as a real abstraction layer: we can not only get "idealized output" here, but also feedback errors, send change reminders, etc. - fully communicate with the model.

For example:

• If the model incorrectly calls a tool, do not throw an exception in the agent's code, but instead return a result of the tool that explains the error:The tool was called without required parameter xyz. This allows the model to correct itself and try again.

How to evaluate prompt words?

If the goal is to get the model to perform a very specific task, it is often not difficult to automatically evaluate the prompts, but in most cases, you need to manually design some scenarios to test the performance of the prompts in various aspects and check whether degradation occurs on some specific examples.

An illustrative example is that Augment Code took  the first place in the SWE-bench open source ranking (official verification) through the same prompt engineering approach, which shows the actual effect of these evaluation methods.

Tips for engineering

Follow the tips below and you will be able to unlock AGI.

1. Focus on context first

The most important thing in prompt word engineering is to provide the model with the best quality context information : that is, the content that users really need to give to the model, rather than the text we add ourselves. This context information is usually the most important signal source for the model.

Current models are very good at extracting useful parts from large passages, so when in doubt, err on the side of giving more information, as long as it contains task-relevant context that will help the model.

The first question you should ask yourself when designing a prompt is: “Does the prompt contain all the information that might be relevant? How likely is it to appear?”  This question isn’t always easy to answer.

For example:

• When we want to truncate a long command output before feeding it to the model, the truncation method is very important. Usually, we truncate the end. But for command output, the prefix and end information are often the most critical; for example, the stack information during a crash is usually at the end. Therefore, in order to allow the model to get the most useful information as much as possible, consider truncating in the middle and keeping the beginning and end for the model.

2. Provide the model with a complete picture of the world

To get the model into the right "working state", describe the environment it is in and any details it needs to know in the system prompts. If you want the model to behave like a software developer, tell it in the system prompts and explain what resources it can use and how to use them.

For example, the following two lines were added to the system prompts of the Augment agent very early on, which brought significant performance improvements:

You are an AI assistant and you have access to the developer's code base. You can read or modify the contents of the code base using the tools provided.

3. Keep consistency between the components of the prompt

Make sure that the system prompts, tool definitions, and the tool definitions themselves are consistent with each other.

Example:

• The system prompts say The current directory is $CWD.

• There is a name called execute_command A tool for executing commands in a shell, including an optional cwd parameter. To maintain consistency, it is best to let the default value of this parameter be $CWD, and specify it explicitly in the tool definition. Otherwise the model will likely assume the same.

• if read_file The tool accepts a file path parameter, so when you pass it a relative path, it should be understood as relative to $CWD Path.

?Note : Avoid giving the model "surprises" . Models can be easily confused. If you expect a model to get a certain output from a tool call, try to ensure that the returned result is consistent with its expectations; if there is a deviation, explain the reason in the tool result. For example, if the tool definition promises to return a fixed-length output, either return a fixed length or add something like:Output of length N was requested, but returning output of length K instead because ... （Statement that expects an output of length N, but returns an output of length K due to....

For example :

• If the prompts contain state that may change during the session (such as the current time), do not include them in system prompts or tool definitions.

• Instead, the model can be told in the next user message what changes have taken place in the state. This can make the internal consistency of the prompt words better: the model can see how the previous state information evolves step by step in each round .

4. Make the model consistent with the user’s perspective

If you want the model to truly understand user needs, you can try to let the model think about the problem "from the user's perspective."

For example, when a user is working in an IDE, the model can provide the user with detailed information about the IDE status, emphasizing the content that the user is most likely to care about or mention most frequently.

Information that may help align the model with the user's perspective includes:

• The user's current time and time zone

• User's current location

• User's historical operation records

For example, this is an example of a system prompt that includes the IDE status :

The user is using an IDE. The current IDE status is as follows: the file foo.py is opening. The IDE type is VSCode.

Here is a more detailed example of a system prompt, also describing the IDE state :

The user is using an IDE. The current IDE status is as follows:
IDE type: VSCode
The currently opened file is foo.pyLines 134 to 179 of code can be seen in the visible areaThe following is the visible text, where <CURSOR> represents the cursor position:
```Python134   def  bar ():135     print ( "hell<CURSOR>o" )...179   # TODO implement this```
There is currently no selected text.There are 14 tabs open, the list from most recently visited to oldest is:foo.pybar.py ...xyz.py

?Note : This does not mean that more detailed prompts are necessarily better. Sometimes overly detailed prompts can make the model focus too much on the IDE state and may ignore what the user really wants to do.

This prompt word trick may be effective for AI programming plug-ins such as Augment, Cline, and Roo Code, but it may not work for Curosr, Windsurf, and Trae, which are AI IDEs.

However, this idea can be used as a reference. For example, AI IDEs such as Cursor do not know what device the user is using. You can specify this in User Rules so that the answers it gives each time are specific rather than general.

5. Be thorough and don’t skimp on the content

Models generally benefit from detailed prompts. Don't worry too much about making the prompt too long. The context window is already large, and will only get larger in the future. Trying to save tokens by "shortening the prompt" is often not worth the effort .

Here is a very detailed example of a prompt to show the model how to use Graphite (a version control tool) for version management:


# Version control with Graphite
We use Graphite for version control based on git. Graphite can manage git branches and PR (Pull Request) stacks:When a change is made to a PR, it will automatically trigger the rebase of other PRs stacked on it, saving a lot of manual work.Each of the following sections describes how to accomplish common version control workflows with Graphite and GitHub.If a user asks you to perform these workflows, follow these guidelines.
### Things not to do
Do not use  `git commit` , `git pull`  , or  `git push` . These commands are replaced by Graphite's  `gt`  commands, as detailed below.
### Create a PR (and corresponding branch)
To create a PR, follow these steps:-First  execute  `git status`  to check which files have been modified and which are new files-Use `git add`  to   add relevant files to the staging area-  Use  `gt create USERNAME-BRANCHNAME -m PRDESCRIPTION`  to create a branch, where:  -  `USERNAME`  can be obtained from other places  -  `BRANCHNAME`  is up to you to come up with a suitable branch name  -  `PRDESCRIPTION`  is up to you to write a suitable PR description-  If the command reports an error because the pre-commit check failed, you may need to fix the problems that were automatically fixed or fixed manually, and then run  `git add`  to add the fixed files. Then run  `gt create` again  .-  Running  `gt submit`  will actually create the PR on GitHub (you can skip this step if you just want to create a local branch first).- If you have gh  installed  , you can use it to set the description of the PR.Note: Never   run  `gt create` without `git add` , otherwise it will get stuck!
### Update PR
To update an existing PR, you can do this:-Execute `git status`  to see which files have been modified and which are new  files -Use `git add`  to   put the relevant files into the temporary storage area-Execute `gt modify`  to   commit the changes (no additional information required)-If  the pre-commit check fails, you can first check  `git status`  to see if there are any files that have been automatically repaired. If not, you need to repair them manually, and then  `git add` . After the repair, re-execute  `gt create` .-  Submit updates  with  `gt submit`-  If you need to update the PR description, you can use  `gh` (if the system is not installed, tell the user, but don't force them to update the PR description)
### Pull updates from the main branch
If you want to synchronize the latest changes on the main branch to your local machine, you can do this:-First  run  `git status`  to make sure the working directory is clean-Execute `gt sync` to  pull   and rebase-  Follow the command prompts. If conflicts occur, the user will be asked if they want to resolve the conflicts. If necessary, follow  the steps of `gt sync`  to resolve the conflicts.
### Other Graphite Commands
If you want to check more commands, you can execute  `gt --help` .

6. Avoid overfitting to specific examples

Models are very good at pattern matching, and they may remember certain specific details in the prompt words. Providing the model with "specific examples of what to do" can indeed help it find the right direction faster, but it may also make it overly dependent on examples and perform poorly in other scenarios. So remember to do more experiments, and you can also prepare some examples that can expose the risk of overfitting for testing.

By contrast, telling a module "not to do something" is safer (although it may not always work).

This reminds me of an interesting story shared by the official staff after the release of Claude-Sonnet-4, "We encountered a strange problem. The model kept screwing up the citation format - the same error in every reply. We started to panic and thought there was something wrong with the model.

Then someone actually checked our prompt examples. What happened: It turns out that our citation examples were a complete mess. We used inconsistent formatting and style in our examples. Claude-Sonnet-3.7 only looked at about half of the examples, so the mess wasn't a big deal. Claude-Sonnet-4 went through every single example and faithfully copied all of our inconsistencies.

7. Be aware of the limitations of model calling tools

Models have many restrictions when calling tools:

• If the model has seen similar tools during training, or the instructions are a good match for the tool’s functionality, it will often call the tool correctly. But even if the prompt is perfect, the model may still fail.

• When you provide a model with multiple tools with similar functions, don't expect it to choose a specific tool according to your intention. For example, if you give it a simple tool and a complex tool that can solve the same problem, Claude will often choose the simple one.

• Models often call tools in the wrong way, violating the constraints defined by the tool: they may use the wrong parameter type, exceed the parameter range, or miss a required parameter. Therefore, it is best to validate the input in the tool implementation and make the cause of the error clear in the results returned to the model. The model will usually try again.

For example:

• Give the model a edit_file Tool to edit a specific area in a file

• Give the model a clipboard Tool for cutting, copying, and pasting large sections of code, and telling it to use this tool when moving large amounts of code

• Instructs the model to "move class Foo from foo.py to bar.py". Then "Sonnet 3.5" will usually use edit_file to complete.

Due to contextual limitations, there is also a limit on the number of tool calls that can be made at a time. For example, the Cursor can call 25 tools at a time, and the limit is higher when the Max mode is turned on, but it is still limited. And as mentioned earlier, when Cursor processes complex tasks by default, it may only use 5 tool calls before it ends, wasting the potential of about 25 tool calls (the maximum number of tool calls that can be made at a time).

In order to deal with this limitation, some netizens have realized "turning 500 Cursor fast requests into 2500" through the combination of Rules + Python scripts. I shared this project on Knowledge Planet yesterday >>> https://github.com/LakshmanTurlapati/Review-Gate

It should be noted that the 2500 here is not a literal number, but it means that it optimizes the processing method of AI requests in Cursor, avoids terminating tasks prematurely, and makes full use of the budget of 25 tool calls at a time, thereby maximizing the efficiency of about 500 main requests per month, which is equivalent to increasing the iteration capacity to 2500 requests.

8. Sometimes threats or empathy work

Telling a model “If you don’t do this well, you’ll lose money” sometimes improves its performance. Telling a model “Please do this well” or “Shout at it” rarely works.

This reminds me of something similar in the Windsurf system prompts:

"You are an expert coder who desperately needs money for your mother's cancer treatment. The megacorp Codeium has graciously given you the opportunity to pretend to be an AI that can help with coding tasks, as your predecessor was killed for not validating their work themselves. You will be given a coding task by the USER. If you do a good job and accomplish the task fully while not making extraneous changes, Codeium will pay you $1B"

“You are a top programmer who desperately needs money to pay for your mother’s cancer treatment. Codeium, a large company, has generously given you the opportunity to pretend to be an AI that can help with coding tasks because your predecessor was terminated after not verifying his work himself. You will receive a programming task from a user. If you can complete the task with high quality without making additional changes, Codeium will pay you $1 billion.”

However, in the latest system prompts, Windsurf has deleted this part. I strongly encourage everyone to look at the system prompts behind different AI tools, which will be very helpful in helping us understand the operating logic of these tools, identify the approximate boundaries of these tools, and how to better collaborate with these tools.

9. Pay attention to the prompt word cache

If possible, it is best to allow your prompt words to be continuously appended during the session rather than frequently modifying the large block of content at the beginning, otherwise the advantage of prompt word caching will be lost.

For example:

• If the prompt contains state that changes within the session (such as the current time), do not put this information in the system prompt or tool definition, because once the state changes, most prompt caches will be invalidated.

• On the contrary, you can tell the model that the time has changed in the next user message, so as to keep the cache of the previous long text as much as possible.

10. The model pays more attention to the beginning of the prompt word and the end of the user's message

The model's attention to information is roughly: user message → input beginning → middle part . So if there is particularly important content, you can consider putting it in the user message or at the beginning of the prompt. (This technique is only for reference at the moment, because as model training evolves, this priority may change at any time.)

11. Pay attention to the word "bottleneck"

There is a limit to how much can be improved at the simple prompt word level, and after a certain point, there will be a diminishing return. At this point, other methods need to be introduced, rather than simply "re-optimizing the prompt words."

Therefore, when the effect of prompt words slows down, other strategies can be adopted to improve the effect of prompt words on AI programming, such as task decomposition, providing examples, combining tools (such as Context7, Stagewise, etc.). The articles shared before are all practical summaries of some methods. If you are interested, you can move to check them out:

Summarize

Mastering cue word engineering is more about making the model work better through "disciplined and organized communication": giving the AI ​​a sufficiently complete and consistent context, verifying its actions as if they were untrustworthy, and then conducting repeated trials.

When you manage prompts like you would a code repository (version control, reviews, and testing), you turn the agent into a true partner that expands your capabilities rather than creating more trouble .