grounded-recommendation

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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.

From ohnotnow/agentic-stuff, MIT.

More from ohnotnow/agentic-stuff