Don’t ask us. Ask Claude.

You posted a question about Claude to people online. First ask Claude. Bring the answer, not the question.

Who can see your problem

The people you asked can only see your question. Claude can read your files, run the command that failed, check your config, fetch the current docs and add up your token usage from your own transcripts. People online have to ask you for more information first, which is slow.

Ask Claude.

This is what I ran, this is what came back, what’s wrong?

If the answer turns out to be wrong, misleading or questionable, you now have something specific to post:

Claude says X, I’m seeing Y.

People don’t want to do the work for you; they want to be interested in the problem. Be interesting. Don’t ask people to think on your behalf.

Why it feels wrong

Asking the tool about the tool feels circular. That’s the stated reason. Often the real one is that you’ve already decided the answer: they changed something. What you want is company, not information. That’s fine. Just say so.

What this looks like

“How do I get this working with X?”

Point Claude at the repo and have it try. It’ll hit the same wall you did, with the error in front of it.

“Why is my usage up?”

Have Claude read your transcripts in ~/.claude/projects and break it down by session.

“What does this error mean?”

Don’t paste it. Let Claude run the thing and read it.

“Does Claude support Y?”

Have it fetch the docs. Its memory of its own features is dated; the docs aren’t.

“Why did it stop following my instructions?”

Ask Claude.

Someone linked you here. They weren’t brushing you off. First ask Claude.