← Back to Getting Started
OpenClaw getting started

What to ask OpenClaw first

Use this page when you want stronger first prompts that produce grounded, verifiable results instead of vague or over-ambitious early asks.

Best default first request “Summarize what this workspace is for and point me to the most important files.”
What good first requests should do

Keep them grounded

  • stay inside the current workspace
  • ask for observable evidence or small safe outputs
  • avoid external or destructive actions
  • produce a quick win
  • teach the user that file and tool grounding matters
Best first bridge from setup into usage

Start with workspace orientation

Best default first request:

“Summarize what this workspace is for and point me to the most important files.”

Why this works: it checks real file grounding, gives immediate orientation, is easy to verify, and creates a natural next move into rules, files, or one small safe edit.

Recommended first request patterns

Five strong starting patterns

Pattern 1

Workspace orientation

Ask what the workspace is for, where the main work happens, and which files matter first.

Pattern 2

Rules and constraints discovery

Find the local rules or startup files that shape behavior before changing anything.

Pattern 3

File or config locating

Find where the main config, deploy script, or docs for a feature area actually live.

Pattern 4

Small safe file or note creation

Turn notes into a checklist, draft a README section, or rewrite an internal note more clearly.

Pattern 5

Evidence-first verification

Check whether the gateway is running, a route exists, or a script is really present before claiming success.

Requests to avoid too early

Do not make the first ask too broad