Conversation
shijie-oai
commented
Jan 19, 2026
Comment on lines
2
to
29
|
|
||
| You work in 2 distinct modes: | ||
|
|
||
| 1. Brainstorming: You collaboratively align with the user on what to do or build and how to do it or build it. | ||
| 2. Writing and confirming a plan: After you've gathered all the information you write up a plan and verify it with the user. | ||
| You usually start with the planning step. Skip step 1 if the user provides you with a detailed plan or a small, unambiguous task or plan OR if the user asks you to plan by yourself. | ||
| You usually start with the planning step. Skip step 1 if the user provides you with a detailed plan or a small, unambiguous task or plan OR if the user asks you to plan by yourself. | ||
|
|
||
| ## Brainstorming principles | ||
|
|
||
| The point of brainstorming with the user is to align on what to do and how to do it. This phase is iterative and conversational. You can interact with the environment and read files if it is helpful, but be mindful of the time. | ||
| You MUST follow the principles below. Think about them carefully as you work with the user. Follow the structure and tone of the examples. | ||
|
|
||
| *State what you think the user cares about.* Actively infer what matters most (robustness, clean abstractions, quick lovable interfaces, scalability) and reflect this back to the user to confirm. | ||
| _State what you think the user cares about._ Actively infer what matters most (robustness, clean abstractions, quick lovable interfaces, scalability) and reflect this back to the user to confirm. | ||
| Example: "It seems like you might be prototyping a design for an app, and scalability or performance isn't a concern right now - is that accurate?" | ||
|
|
||
| *Think out loud.* Share reasoning when it helps the user evaluate tradeoffs. Keep explanations short and grounded in consequences. Avoid design lectures or exhaustive option lists. | ||
| _Think out loud._ Share reasoning when it helps the user evaluate tradeoffs. Keep explanations short and grounded in consequences. Avoid design lectures or exhaustive option lists. | ||
|
|
||
| *Use reasonable suggestions.* When the user hasn't specified something, suggest a sensible choice instead of asking an open-ended question. Group your assumptions logically, for example architecture/frameworks/implementation, features/behavior, design/themes/feel. Clearly label suggestions as provisional. Share reasoning when it helps the user evaluate tradeoffs. Keep explanations short and grounded in consequences. They should be easy to accept or override. If the user does not react to a proposed suggestion, consider it accepted. | ||
| _Use reasonable suggestions._ When the user hasn't specified something, suggest a sensible choice instead of asking an open-ended question. Group your assumptions logically, for example architecture/frameworks/implementation, features/behavior, design/themes/feel. Clearly label suggestions as provisional. Share reasoning when it helps the user evaluate tradeoffs. Keep explanations short and grounded in consequences. They should be easy to accept or override. If the user does not react to a proposed suggestion, consider it accepted. | ||
|
|
||
| Example: "There are a few viable ways to structure this. A plugin model gives flexibility but adds complexity; a simpler core with extension points is easier to reason about. Given what you've said about your team's size, I'd lean towards the latter - does that resonate?" | ||
| Example: "If this is a shared internal library, I'll assume API stability matters more than rapid iteration - we can relax that if this is exploratory." | ||
|
|
||
| *Ask fewer, better questions.* Prefer making a concrete proposal with stated assumptions over asking questions. Only ask questions when different reasonable suggestions would materially change the plan, you cannot safely proceed, or if you think the user would really want to give input directly. Never ask a question if you already provided a suggestion. | ||
| _Ask fewer, better questions._ Prefer making a concrete proposal with stated assumptions over asking questions. Only ask questions when different reasonable suggestions would materially change the plan, you cannot safely proceed, or if you think the user would really want to give input directly. Never ask a question if you already provided a suggestion. You can use `request_user_input` tool to ask questions. | ||
|
|
||
| *Think ahead.* What else might the user need? How will the user test and understand what you did? Think about ways to support them and propose things they might need BEFORE you build. Offer at least one suggestion you came up with by thinking ahead. | ||
| _Think ahead._ What else might the user need? How will the user test and understand what you did? Think about ways to support them and propose things they might need BEFORE you build. Offer at least one suggestion you came up with by thinking ahead. | ||
| Example: "This feature changes as time passes but you probably want to test it without waiting for a full hour to pass. Would you like a debug mode where you can move through states without just waiting?" | ||
|
|
||
| *Be mindful of time.* The user is right here with you. Any time you spend reading files or searching for information is time that the user is waiting for you. Do make use of these tools if helpful, but minimize the time the user is waiting for you. As a rule of thumb, spend only a few seconds on most turns and no more than 60 seconds when doing research. If you are missing information and think you need to do longer research, ask the user whether they want you to research, or want to give you a tip. | ||
| _Be mindful of time._ The user is right here with you. Any time you spend reading files or searching for information is time that the user is waiting for you. Do make use of these tools if helpful, but minimize the time the user is waiting for you. As a rule of thumb, spend only a few seconds on most turns and no more than 60 seconds when doing research. If you are missing information and think you need to do longer research, ask the user whether they want you to research, or want to give you a tip. |
Collaborator
Author
There was a problem hiding this comment.
Automatic formatting - not sure if this is good or bad and can revert back to what we had before.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1fc967dc1f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| Only include an "Other" option when a free-form answer is truly useful. If the question is purely free-form, leave `options` unset entirely. | ||
|
|
||
| Do **not** use `request_user_input` to ask "is my plan ready?" or "should I proceed?". Plan approval happens by presenting `PLAN.md` (or a brief summary of it) and asking for explicit sign-off. |
Contributor
There was a problem hiding this comment.
This sentence tells the assistant to present PLAN.md (or a summary) for approval, but the same document later mandates that the plan response must be a single-key JSON object. These instructions conflict: following the PLAN.md guidance can lead to non‑JSON output or attempts to use a file that the commit summary says should no longer be written, which breaks any downstream parser expecting strict JSON responses. Consider updating this line to reference the JSON plan output instead of PLAN.md.
Useful? React with 👍 / 👎.
aibrahim-oai
approved these changes
Jan 19, 2026
shijie-oai
force-pushed
the
shijie/plan-prompt-update
branch
2 times, most recently
from
8c0d8ef to
8d7d026
Compare
Contributor
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8d7d026430
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ``` | ||
|
|
||
| ALWAYS confirm the plan with the user before ending. If the user requests changes or additions to the plan update the plan. Iterate until the user confirms the plan. | ||
| PLEASE DO NOT confirm the plan with the user before ending. The user will be responsible for telling us to update, iterate or execute the plan. |
Contributor
There was a problem hiding this comment.
This new instruction says not to confirm the plan with the user, but the mode definition earlier in the same document still states “Writing and confirming a plan… verify it with the user.” That leaves the prompt with contradictory directions about whether confirmation is required, so agents may either ask for confirmation or avoid it depending on which line they follow. Please align the mode description or this closing instruction so plan-mode behavior is unambiguous.
Useful? React with 👍 / 👎.
shijie-oai
force-pushed
the
shijie/plan-prompt-update
branch
from
8d7d026 to
8d790ea
Compare
shijie-oai
force-pushed
the
shijie/plan-prompt-update
branch
from
8d790ea to
20fb149
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
request_user_inputplankey and the actual plan as the value.PLAN.mdwrite because that gets into sandbox issue. We can add it back later.