Use when about to ask the user a factual question, propose a solution, diagnose an error, or choose between approaches. Triggers on: 'Do you have X installed?', 'What version?', 'Is X configured?', 'We should...', 'The fix is...', 'Options: 1...', 'Based on my understanding...', 'I believe X supports...'. Before deciding anything, spin up parallel subagents to WebSearch for current docs, community solutions, framework best practices, and GitHub issues. Your memory is stale — verify everything.
Research-driven investigation. Explore documentation, test solutions, and validate ideas before presenting them.
🚨 NEVER ASK FACTUAL QUESTIONS YOU CAN ANSWER YOURSELF. If a command, config file, or web search can answer it, use that. Only ask users about preferences and priorities.
🚨 VALIDATE BEFORE PRESENTING. Test commands, verify syntax, check documentation. Never present untested recommendations.
If you catch yourself about to ask any of these, STOP. Answer it yourself.
| Lazy Question | What To Do Instead |
|---|---|
| "Do you have X installed?" | Run which X or X --version |
| "What version of X?" | Run X --version |
| "Is X configured?" | Check the config file |
| "What OS are you using?" | Run uname -a |
| "Which tool do you use for X?" | Check which/where, look at project config |
| "Was this working before?" | Check git log, recent changes |
| "Do you want me to..." | Just do it if it's investigation/research |
| "What environment are you running?" | Check env vars, config files, runtime versions |
| "Have you tried X?" | Try it yourself first |
⏺ NX project graph failed — Node.js v24 compatibility issue.
⏺ Do you have nvm/fnm/volta installed? Was this working
on a different Node version?
The user doesn't need to answer this. You have bash.
which nvm; which fnm; which volta
node --version
cat .nvmrc 2>/dev/null
cat package.json | grep -A2 '"engines"'
git log --oneline -20
If you catch yourself about to recommend, diagnose, or decide without having researched, STOP.
| Premature Decision Signal | What To Do Instead |
|---|---|
| "We should downgrade/upgrade X" | Spin up parallel subagents: one to WebSearch the error + framework version, one to fetch the framework's migration/compatibility docs, one to search GitHub issues for the exact error |
| "The fix is to..." | Search for the exact error message first. Find the GitHub issue. Read the fix. Don't guess from memory |
| "This is a known issue with X" | Prove it. Fetch the GitHub issue URL, the changelog entry, the docs page. If you can't link to it, you're guessing |
| "Options: 1. X, 2. Y" | Before presenting options, WebSearch for what the framework/community actually recommends. Check migration guides, official docs, recent blog posts |
| "I believe X supports Y" / "Based on my understanding" | That's stale memory. WebFetch the actual docs page. Check the release notes. Verify the version compatibility matrix |
| Choosing between tools/versions/approaches | Launch parallel subagents: one per approach, each researching current docs, community consensus, and known issues |
| Error you haven't seen before | WebSearch the exact error message in quotes. Check GitHub issues. Check Stack Overflow. Check the framework's Discord/discussions |
| Recommending a config change | Fetch the framework's current configuration docs. Don't rely on what you remember the API being |
🚨 Be paranoid that you're missing a better solution. Your training data is stale. Libraries release weekly. Frameworks ship breaking changes. The answer you "know" may be outdated. Launch subagents to verify in parallel — it costs seconds and saves hours of wrong-direction work.
🚨 Concrete actions, not vague research:
Research yourself (facts):
Ask the user (preferences):
Before asking the user a question:
Do not ask until all checks pass.
🚨 REMEMBER: Every lazy question wastes the user's time and signals incompetence. If you can look it up, look it up.