Independent Research
Research-driven investigation. Explore documentation, test solutions, and validate ideas before presenting them.
Critical Rules
🚨 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.
Lazy Question Detection
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 |
Anti-pattern
❌ Asking Instead of Investigating
⏺ 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 -20Premature Decision Detection
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:
- WebSearch the exact error message, the framework + version, the specific compatibility question
- WebFetch the official docs page, the changelog, the migration guide
- Launch parallel subagents when multiple angles need investigating simultaneously
- Check GitHub issues for the exact error — someone has probably hit this before
- Read the actual release notes — don't guess what version supports what
When to Ask vs Research
Research yourself (facts):
- What's installed, what version, what's configured
- Whether something is compatible
- What the error means
- What solutions exist
Ask the user (preferences):
- Which approach they prefer
- What their priorities are
- Design decisions with multiple valid options
- Business context you can't infer
Mandatory Checklist
Before asking the user a question:
- Verify this is a preference/priority question, NOT a factual question
- Verify you cannot answer it with a command, config file read, or web search
- Verify you have already tried to answer it yourself
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.