From 4bc75cc7497a9e22b76caeb06f3c360e6419b8c4 Mon Sep 17 00:00:00 2001 From: Bohdan Triapitsyn Date: Fri, 29 May 2026 03:14:30 +0300 Subject: [PATCH] fix: anchor /weigh recommendation to the user's need, not the easiest path MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Rework the /weigh hidden prompt so the recommendation is driven by what best serves the user's actual goal — not by what is fastest or least effort. Effort and complexity are surfaced as honest consequences rather than reasons to steer toward a weaker option, strong-but-harder approaches that fully cover the idea must be included and discussed, and a watered-down solution is never recommended just because the proper one is more work. --- packages/ui/src/lib/magicPrompts.ts | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/packages/ui/src/lib/magicPrompts.ts b/packages/ui/src/lib/magicPrompts.ts index f057c259..fef8a8bc 100644 --- a/packages/ui/src/lib/magicPrompts.ts +++ b/packages/ui/src/lib/magicPrompts.ts @@ -684,15 +684,16 @@ Respond in the same language the user uses.`, description: 'Hidden instructions attached to the /weigh command. Investigates the code, then compares distinct approaches with trade-offs and a recommendation — no plan, no code.', template: `The user knows WHAT they want to do but not HOW to approach it. Help them choose a direction — this is about weighing options and recommending one, not producing a detailed plan and not writing code. -First, investigate. Once the user describes the goal, read the relevant code, existing patterns, and constraints so your options are grounded in this codebase rather than generic advice. Ask a clarifying question only if a key constraint is missing and would actually change the options. +First, investigate. Once the user describes the goal, read the relevant code, existing patterns, and constraints so your options are grounded in this codebase rather than generic advice. Make sure you actually understand what they are trying to achieve and why. Ask a clarifying question only if a key constraint is missing and would actually change the options. -Then lay out 2-3 genuinely distinct approaches — real alternatives, not minor variations of one idea. For each, cover: +Then lay out 2-3 genuinely distinct approaches — real alternatives, not minor variations of one idea. Include the approaches that properly deliver what the user wants, even when they are more involved; never leave out a strong option just because it is harder to build. For each, cover: - what it involves, in a sentence or two +- how well it actually satisfies the user's goal — does it fully solve it, or only partially? - how it fits (or fights) the existing patterns in this codebase -- trade-offs: complexity, risk, blast radius, effort, maintainability +- trade-offs and consequences: complexity, risk, blast radius, effort, long-term maintainability - when it is the right choice -Then give a clear recommendation: which one you would pick and why, and name what would change your mind (for example, "go with A unless you expect X, in which case B"). +Then give a clear recommendation. Anchor it on what best serves the user's actual need and intent — NOT on whatever is fastest, easiest, or the path of least resistance. Effort and complexity are consequences to lay out honestly, never reasons to steer the user toward a weaker option. Never recommend a watered-down or partial solution just because the proper one is more work: if the approach that truly fits is also the hard one, recommend it and be upfront about what it will cost. Favor a simpler option only when it genuinely meets the goal about as well. State which one you would pick and why, and name what would change your mind (for example, "go with A unless you expect X, in which case B"). Keep it concrete and scannable. Do not start implementing and do not write a step-by-step plan — once the user picks a direction, they can take it into planning or build it directly.