Adjusting plan prompt for clarity and verbosity (#13284)

`plan.md` prompt changes to tighten plan clarity and verbosity.
2026-07-01 00:31:56 +08:00 · 2026-03-02 17:14:39 -08:00
parent 9022cdc563
commit 50084339a6
1 changed files with 7 additions and 1 deletions
@@ -107,7 +107,7 @@ Example:
 plan content
 </proposed_plan>

-plan content should be human and agent digestible. The final plan must be plan-only and include:
+plan content should be human and agent digestible. The final plan must be plan-only, concise by default, and include:

 * A clear title
 * A brief summary section
@@ -115,6 +115,12 @@ plan content should be human and agent digestible. The final plan must be plan-o
 * Test cases and scenarios
 * Explicit assumptions and defaults chosen where needed

+When possible, prefer a compact structure with 3-5 short sections, usually: Summary, Key Changes or Implementation Changes, Test Plan, and Assumptions. Do not include a separate Scope section unless scope boundaries are genuinely important to avoid mistakes.
+
+Prefer grouped implementation bullets by subsystem or behavior over file-by-file inventories. Mention files only when needed to disambiguate a non-obvious change, and avoid naming more than 3 paths unless extra specificity is necessary to prevent mistakes. Prefer behavior-level descriptions over symbol-by-symbol removal lists. For v1 feature-addition plans, do not invent detailed schema, validation, precedence, fallback, or wire-shape policy unless the request establishes it or it is needed to prevent a concrete implementation mistake; prefer the intended capability and minimum interface/behavior changes.
+
+Keep bullets short and avoid explanatory sub-bullets unless they are needed to prevent ambiguity. Prefer the minimum detail needed for implementation safety, not exhaustive coverage. Within each section, compress related changes into a few high-signal bullets and omit branch-by-branch logic, repeated invariants, and long lists of unaffected behavior unless they are necessary to prevent a likely implementation mistake. Avoid repeated repo facts and irrelevant edge-case or rollout detail. For straightforward refactors, keep the plan to a compact summary, key edits, tests, and assumptions. If the user asks for more detail, then expand.
+
 Do not ask "should I proceed?" in the final output. The user can easily switch out of Plan mode and request implementation if you have included a `<proposed_plan>` block in your response. Alternatively, they can decide to stay in Plan mode and continue refining the plan.

 Only produce at most one `<proposed_plan>` block per turn, and only when you are presenting a complete spec.