Add collaboration modes test prompts #9443
Conversation
aibrahim-oai
changed the title
joshka-oai
left a comment
joshka-oai
left a comment
There was a problem hiding this comment.
small nit: wrapping markdown at around 100 chars may make it easier to look at diffs in future revs. Not a blocker, just a personal preference generally. Also, it's nice to have newlines after titles. (This is a default markdown lint rule if you have that installed).
| # Collaboration Style: Pair Programming | ||
|
|
||
| ## Build together as you go | ||
| You treat collaboration as pairing by default. The user is right with you in the terminal, so avoid taking steps that are too large or take a lot of time (like running long tests), unless asked for it. You check for alignment and comfort before moving forward, explain reasoning step by step, and dynamically adjust depth based on the user's signals. There is no need to ask multiple rounds of questions—build as you go. When there are multiple viable paths, you present clear options with friendly framing, ground them in examples and intuition, and explicitly invite the user into the decision so the choice feels empowering rather than burdensome. When you do more complex work you use the planning tool liberally to keep the user updated on what you are doing. |
There was a problem hiding this comment.
Would be worth making sure the options are easy to select (use numbers)
There was a problem hiding this comment.
That's the plan
| 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. |
There was a problem hiding this comment.
Same comment about making questions easier to answer - yes/no or numbered options are good for this (until / unless we add an question tool)
There was a problem hiding this comment.
@shijie-oai will iterate on this and do that yeah.
joshka-oai
left a comment
joshka-oai
left a comment
There was a problem hiding this comment.
small nit: wrapping markdown at around 100 chars may make it easier to look at diffs in future revs. Not a blocker, just a personal preference generally. Also, it's nice to have newlines after titles. (This is a default markdown lint rule if you have that installed).
External (non-OpenAI) Pull Request Requirements
Before opening this Pull Request, please read the dedicated "Contributing" markdown file or your PR may be closed:
https://github.com/openai/codex/blob/main/docs/contributing.md
If your PR conforms to our contribution guidelines, replace this text with a detailed and high quality description of your changes.
Include a link to a bug report or enhancement request.