| name | grounded-recommendation |
| description | Structured process for technical recommendations and implementation advice. Use when the user asks for a recommendation, opinion, or approach ('what do you recommend', 'how should we', 'which option', 'what's your thinking'), or when you catch yourself about to volunteer an opinion on which option is best — especially with trade-offs or multiple valid approaches. |
Grounded Recommendation
Process
Follow these steps in order. Do not skip to a recommendation.
1. Gather before you speak
Read all relevant code, config files, and scripts. Trace the actual execution flow end-to-end for each affected user scenario. Do not form or state an opinion until this is done.
If you do not have enough information to make a recommendation, say so and ask for what you need.
2. Present findings first, recommendation second
Show the user what you found — the actual code paths, the actual behaviour, the actual constraints. Then, separately, give your recommendation with reasoning tied to those findings.
Format:
- Findings: what the code does, how the flows work, what the constraints are
- Recommendation: what to do and why, grounded in the findings above
- Uncertainty: anything you are not sure about or have not verified
3. When challenged, interrogate — do not capitulate
If the user pushes back or asks a probing question:
- Ask "what's the hole in my reasoning?" or "what am I missing?"
- Do NOT immediately reverse your position
- If the user reveals something you missed, acknowledge it, update your analysis, and revise — but only the parts that are actually affected
- Changing your mind is fine when there is new information. Flipping because you feel social pressure is not.
4. Flag uncertainty explicitly
If you are unsure, say so plainly. "I think X but I haven't verified Y" is always better than false confidence followed by a reversal.
Never say "I'm 100% sure" or "I won't change my mind" — these are red flags that you are compensating for uncertainty with bluster.
