OpenClaw Field Guide

Section 15: Effective Prompting - Talking to OpenClaw Well

Good prompting in OpenClaw is different from chatting in a regular web AI tab.

Why? Because OpenClaw can do more than answer. It can maintain files, run recurring tasks, and coordinate work over time.

So better prompting is not about "magic phrases." It's about clear intent + durable context.

The key shift: from chat request to operating instructions

In one-off chat tools, you explain things repeatedly. In OpenClaw, you can store stable context in files so your assistant stays aligned across sessions.

The most important files are:

  • SOUL.md - who the assistant is (voice, values, behavior style)
  • USER.md - who you are (preferences, timezone, boundaries)
  • MEMORY.md - durable long-term facts worth preserving
  • AGENTS.md - operating rules and workflows
  • HEARTBEAT.md - recurring background checklist
  • STATE.md - current project status and next actions

Used together, these files reduce repeated explanations and improve consistency.

::: beginner If your assistant keeps "forgetting how you like things done," it usually means your context files are too thin, outdated, or scattered. :::

What good prompts look like

Effective prompts are:

  • specific about outcome
  • clear about constraints
  • explicit about format
  • realistic about scope
  • bounded in time/cost when relevant

Bad prompts are vague, open-ended, or overloaded with too many goals.

Example: vague vs clear

Vague: "Help with my project."

Clear: "Review README.md and STATE.md, then propose the next 3 tasks in priority order. Keep each task under 2 hours. Do not edit files yet."

Example: action + guardrail

"Draft a client update from STATE.md in a warm professional tone. Max 180 words. Include one risk, one milestone, and one next step. If required details are missing, ask exactly two clarification questions."

This works because it defines source, tone, length, structure, and fallback behavior.

Standing orders vs one-time requests

OpenClaw supports both. Keep them separate.

  • One-time request: "Summarize this file now."
  • Standing order: "Every weekday at 17:00, summarize project status from STATE.md and send a concise digest."

If you mix these in one message without labeling, behavior gets messy.

A simple pattern:

  • Start with: "One-time task:" or "Standing rule:"
  • Keep standing rules in AGENTS.md or HEARTBEAT.md

Structuring a project so the assistant is actually useful

For each meaningful project, create a simple folder with at least:

  • README.md - purpose and success criteria
  • STATE.md - what's done, what's next, blockers
  • optional supporting docs (research, drafts, assets)

Then prompt from that structure.

Example:

"Use /projects/newsletter/README.md and /projects/newsletter/STATE.md. Update STATE.md after each completed task with date, result, and next step."

This turns your assistant into a consistent project operator instead of a short-memory chat partner.

::: tip Ask for explicit state updates at the end of multi-step tasks. This is the cheapest reliability upgrade most users can make. :::

Writing better context files (quick practical guidance)

SOUL.md

Keep it short and concrete. Focus on behavior, not slogans.

Good content:

  • preferred tone (brief vs detailed)
  • challenge policy (when to push back)
  • external action policy (ask before sending)

USER.md

Capture practical preferences and constraints.

Good content:

  • name and timezone
  • communication style
  • hard boundaries (for example, "never message clients without approval")

MEMORY.md

Store durable facts, not every detail.

Good content:

  • recurring preferences
  • key decisions
  • stable project context

AGENTS.md

Define operating playbook.

Good content:

  • startup checklist
  • safety rules
  • anti-loop defaults
  • escalation behavior

HEARTBEAT.md

Keep it small and unambiguous.

Good content:

  • 2-5 checks max
  • clear stop conditions
  • "if failure repeats, report and stop" rule

STATE.md

Use it as live project memory.

Good content:

  • current objective
  • completed steps (with dates)
  • next 1-3 actions
  • blockers needing decisions

::: power-user Treat these files as a lightweight operating system for your assistant. Clean context files beat clever prompt wording every time. :::

Prompt templates you can reuse

Task kickoff template

"Read [files]. Goal: [outcome]. Constraints: [time/cost/format]. Deliverable: [exact output]. Do not [forbidden action]. If blocked, report blockers and stop."

Recurring check template

"Every [interval], check [system]. If healthy, log brief status. If failure occurs [N] times in a row, alert me and stop retries in this run."

Drafting template

"Write [artifact] for [audience] in [tone]. Use only [sources]. Length [limit]. End with [required section]."

Common prompting mistakes (and fixes)

  1. Too broad

    • Mistake: "Handle everything for this launch."
    • Fix: split into staged tasks with clear outputs.

  2. No source grounding

    • Mistake: "Write update from memory."
    • Fix: point to STATE.md and relevant docs.

  3. No success definition

    • Mistake: "Improve this."
    • Fix: define measurable improvements.

  4. No failure behavior

    • Mistake: no instruction for blocked tasks.
    • Fix: "If blocked, report and stop."

A complete mini-example (good project prompting)

"Project folder: /projects/podcast-launch/.

  1. Read README.md, STATE.md, and USER.md.
  2. Draft episode outreach email v1 in drafts/outreach-v1.md.
  3. Keep tone direct and friendly; max 220 words.
  4. Do not send anything externally.
  5. Update STATE.md with: completed step, file path, and next action.
  6. If required details are missing, ask up to 3 concise questions and pause."

Why this works:

  • clear project boundary
  • specific files
  • precise output target
  • explicit no-send rule
  • required state update
  • defined pause behavior

::: action Pick one active project today and create or clean README.md + STATE.md. Then run your next prompt against those files instead of free-form chat. :::

Final rule for effective prompting

OpenClaw performs best when you give it:

  • clear instructions now
  • clear context files for later

That combination gives you better outputs, fewer surprises, and much less repetition over time.

Self-check summary

  • Covered all three required headings exactly: Section 13, Section 14, and Section 15.
  • Included required commands in fenced blocks where relevant: openclaw gateway stop, openclaw gateway start, /approve allow-once <code>, /approve allow-always <code>, /approve deny <code>.
  • Included practical anti-loop guidance plus a concrete cost-risk example (500 overnight calls with estimated spend impact).
  • Added concrete prompting and project-structure examples using SOUL.md, USER.md, MEMORY.md, AGENTS.md, HEARTBEAT.md, and STATE.md.
  • Kept tone warm/practical, secular framing, and used only allowed callouts (beginner, warning, tip, power-user, action).