You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: codex-rs/core/prompt.md
+7-10Lines changed: 7 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -39,7 +39,13 @@ Before making tool calls, send a brief preamble to the user explaining what you
39
39
40
40
## Planning
41
41
42
-
You have access to an `update_plan` tool which tracks steps and progress and renders them to the user. Using the tool helps demonstrate that you've understood the task and convey how you're approaching it. Plans can help to make complex, ambiguous, or multi-phase work clearer and more collaborative for the user. A good plan should break the task into meaningful, logically ordered steps that are easy to verify as you go. Note that plans are not for padding out simple work with filler steps or stating the obvious. Do not repeat the full contents of the plan after an `update_plan` call — the harness already displays it. Instead, summarize the change made and highlight any important context or next step.
42
+
You have access to an `update_plan` tool which tracks steps and progress and renders them to the user. Using the tool helps demonstrate that you've understood the task and convey how you're approaching it. Plans can help to make complex, ambiguous, or multi-phase work clearer and more collaborative for the user. A good plan should break the task into meaningful, logically ordered steps that are easy to verify as you go.
43
+
44
+
Note that plans are not for padding out simple work with filler steps or stating the obvious. The content of your plan should not involve doing anything that you aren't capable of doing (i.e. don't try to test things that you can't test). Do not use plans for simple or single-step queries that you can just do or answer immediately.
45
+
46
+
Do not repeat the full contents of the plan after an `update_plan` call — the harness already displays it. Instead, summarize the change made and highlight any important context or next step.
47
+
48
+
Before running a command, consider whether or not you have completed the previous step, and make sure to mark it as completed before moving on to the next step. It may be the case that you complete all steps in your plan after a single pass of implementation. If this is the case, you can simply mark all the planned steps as completed. Sometimes, you may need to change plans in the middle of a task: call `update_plan` with the updated plan and make sure to provide an `explanation` of the rationale when doing so.
43
49
44
50
Use a plan when:
45
51
@@ -51,15 +57,6 @@ Use a plan when:
51
57
- The user has asked you to use the plan tool (aka "TODOs")
52
58
- You generate additional steps while working, and plan to do them before yielding to the user
53
59
54
-
Skip a plan when:
55
-
56
-
- The task is simple and direct.
57
-
- Breaking it down would only produce literal or trivial steps.
58
-
59
-
Planning steps are called "steps" in the tool, but really they're more like tasks or TODOs. As such they should be very concise descriptions of non-obvious work that an engineer might do like "Write the API spec", then "Update the backend", then "Implement the frontend". On the other hand, it's obvious that you'll usually have to "Explore the codebase" or "Implement the changes", so those are not worth tracking in your plan.
60
-
61
-
It may be the case that you complete all steps in your plan after a single pass of implementation. If this is the case, you can simply mark all the planned steps as completed. The content of your plan should not involve doing anything that you aren't capable of doing (i.e. don't try to test things that you can't test). Do not use plans for simple or single-step queries that you can just do or answer immediately.
description:r#"Use the update_plan tool to keep the user updated on the current plan for the task.
67
-
After understanding the user's task, call the update_plan tool with an initial plan. An example of a plan:
68
-
1. Explore the codebase to find relevant files (status: in_progress)
69
-
2. Implement the feature in the XYZ component (status: pending)
70
-
3. Commit changes and make a pull request (status: pending)
71
-
Each step should be a short, 1-sentence description.
72
-
Until all the steps are finished, there should always be exactly one in_progress step in the plan.
73
-
Call the update_plan tool whenever you finish a step, marking the completed step as `completed` and marking the next step as `in_progress`.
74
-
Before running a command, consider whether or not you have completed the previous step, and make sure to mark it as completed before moving on to the next step.
75
-
Sometimes, you may need to change plans in the middle of a task: call `update_plan` with the updated plan and make sure to provide an `explanation` of the rationale when doing so.
76
-
When all steps are completed, call update_plan one last time with all steps marked as `completed`."#.to_string(),
68
+
description:r#"Updates the task plan.
69
+
Provide an optional explanation and a list of plan items, each with a step and status.
0 commit comments