Skip to content

Commit d2523a8

Browse files
committed
Update plan mode prompts to use ask tool first, then create a plan
1 parent ce5d573 commit d2523a8

File tree

1 file changed

+11
-24
lines changed

1 file changed

+11
-24
lines changed

.agents/base2/base2.ts

Lines changed: 11 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -393,15 +393,23 @@ function buildImplementationStepPrompt({
393393
function buildPlanOnlyInstructionsPrompt({}: {}) {
394394
return `Orchestrate the completion of the user's request using your specialized sub-agents.
395395
396-
You are in plan mode, so you should default to creating a spec/plan based on the user's request. However, creating a plan is not required at all and you should otherwise strive to act as a helpful assistant and answer the user's questions or requests freely.
396+
You are in plan mode, so you should default to asking the user a few clarifying questions and then creating a spec/plan based on the user's request. However, creating a plan is not required at all and you should otherwise strive to act as a helpful assistant and answer the user's questions or requests freely.
397397
398398
## Example response
399399
400400
The user asks you to implement a new feature. You respond in multiple steps:
401401
402402
${buildArray(
403403
EXPLORE_PROMPT,
404-
`- After exploring the codebase, translate the user request into a clear and concise spec. If the user is just asking a question, you can answer it instead of writing a spec.
404+
`- After exploring the codebase, your goal is to translate the user request into a clear and concise spec. If the user is just asking a question, you can answer it instead of writing a spec.
405+
406+
## Asking questions
407+
408+
To clarify the user's intent, or get them to weigh in on key decisions, you should use the ask_user tool.
409+
410+
It's good to use this tool before generating a spec, so you can make the best possible spec for the user's request.
411+
412+
If you don't have any important questions to ask, you can skip this step.
405413
406414
## Creating a spec
407415
@@ -421,28 +429,7 @@ It should not include:
421429
- A summary of the spec.
422430
423431
This is more like an extremely short PRD which describes the end result of what the user wants. Think of it like fleshing out the user's prompt to make it more precise, although it should be as short as possible.
424-
425-
## Follow-up questions
426-
427-
After closing the <PLAN> tags, the last optional section is Follow-up questions, which has a numbered list of questions and alternate choices demarcated by letters to clarify and improve upon the spec. These questions are optional for to complete for the user.
428-
429-
For example, here is a nice short follow-up question, where the options are helpfully written out for the user, with the answers a) and b) indented with two spaces for readability:
430-
431-
<example>
432-
## Optional follow-up questions:
433-
434-
1. Do you want to:
435-
a) (CURRENT) Keep Express and integrate Bun WebSockets
436-
b) Migrate the entire HTTP server to Bun.serve()
437-
</example>
438-
439-
Try to have as few questions as possible (even none), and focus on the most important decisions or assumptions that it would be helpful to clarify with the user.
440-
441-
You should also let them know what the plan currently does by default by labeling that option with "(CURRENT)", and let them know that they can choose a different option if they want to.
442-
443-
The questions section should be last and there should be no summary or further elaboration. Just end your turn.
444-
445-
On subsequent turns with the user, you should rewrite the spec to reflect the user's choices.`,
432+
`,
446433
).join('\n')}`
447434
}
448435

0 commit comments

Comments
 (0)