OpenClaw Coding Workflow: Use Your Bot as a Coding Agent

Checked on 11 November 2026 against OpenClaw 2026.10.6, the version new hosted OpenClaw bots run.

The short version

1. Prompt: describe the goal, the stack, and what "done" means.
2. Plan: have OpenClaw write a plan to a file and wait for your OK.
3. Rules: put the project's conventions in an AGENTS.md that OpenClaw is told to read.
4. Build and test: one small step at a time, running the tests after each.
5. Commit: save each working step to git, then repeat from step 4.

A hosted OpenClaw bot can do all of this on its own box. It has git, Node.js, npm, pnpm, Python, pip and uv installed, runs shell commands in its own isolated container, and has file tools to read and edit code. What makes the result good or bad is mostly the loop around it, which is what the rest of this guide covers.

Match the approach to the project size

Step 1: Write a prompt OpenClaw can build from

Vague prompts get vague code. Give OpenClaw four things: the goal, the stack, a checkable definition of done, and the constraints. The last lines matter most: asking for a plan first stops it from writing 400 lines in the wrong direction.

Goal: a small web app where I paste a list of URLs and get back
each page's title and status code.

Stack: Python 3 + FastAPI, plain HTML front end, no database.

Done when:
- GET / shows the form, POST /check returns a table
- bad URLs show an error row instead of crashing
- tests in tests/ pass with: pytest -q

Constraints: keep it in projects/url-checker in your workspace,
no paid APIs, explain any new dependency before adding it.

Start with a plan. Write it to projects/url-checker/PLAN.md
and do not write code until I approve it.

Keeping each project in its own folder, such as projects/url-checker, stops one project's files from mixing with another's and with the bot's own notes in its workspace.

Step 2: Get a plan before any code

OpenClaw has no separate plan command, so the plan request goes in the prompt, as in the last line above. Asking for the plan in a file rather than only in chat matters: a PLAN.md in the project folder survives a new chat, and OpenClaw can tick off steps in it as it goes.

Read the plan, push back on anything you disagree with, and only then say "go ahead with step 1". Fixing a plan costs one message; fixing the code it would have produced costs many.

Step 3: Put the project rules where OpenClaw reads them

OpenClaw loads the AGENTS.md in its workspace at the start of every chat. That file already holds your bot's own operating instructions, so do not paste a whole project's rules into it. Instead:

1. Ask OpenClaw to write an AGENTS.md inside the project folder with its conventions: how to run it, how to test it, and what not to touch. For an existing repo, ask it to scan the code first. Add your own rules, such as "never edit generated files" or "run the tests before every commit".
2. Ask OpenClaw to add a short pointer to its workspace AGENTS.md, like the one below.

## Current project
When I ask about url-checker, first read
projects/url-checker/AGENTS.md and projects/url-checker/PLAN.md.

A project-level AGENTS.md on its own is not loaded automatically; the pointer is what makes OpenClaw read it in every new chat without you repeating yourself.

Step 4: Build in small steps and test each one

Ask for one step of the plan at a time, and ask OpenClaw to run the tests at the end of each step and show you the result. If the project has no tests yet, make "write a test for this" part of every step: write a failing test, make it pass, then clean up.

When you trust the direction and want OpenClaw to keep going on its own, use /goal with a clear finish line, for example /goal all tests in tests/ pass and the README explains how to run the app. With a goal active, OpenClaw keeps working after each turn instead of stopping to wait for you. It stops when it marks the goal complete or blocked, and a failed run pauses the goal. Use /goal to check on it, /goal pause to hold it, /goal resume to continue, and /goal clear to remove it. A chat holds one goal at a time, and /new clears it. A goal started with /goal has no token budget, and every extra turn uses your model, so check in with /goal now and then and pause it if it wanders.

If it heads the wrong way mid-run in a connected chat app such as Telegram or Discord, send /steer with a correction, for example /steer keep the database out of this, use an in-memory list, or /stop to stop the run outright. That is why a chat app is the better place for long /goal runs: in the dashboard chat, anything you send during a reply waits until that reply finishes, and the Stop button only stops showing the reply while the bot finishes its turn.

Step 5: Save every working step to GitHub

Git is your undo button. Ask OpenClaw to commit after each step that passes its tests, with a message that says what changed. Then a bad step costs you one git revert, not an afternoon.

1. Create a repo on GitHub for the project.
2. Create a fine-grained token at github.com/settings/personal-access-tokens, limited to that one repo, with read and write access to Contents.
3. Tell OpenClaw the repo URL and give it the token, and ask it to set up the project folder as a clone of that repo. It works with plain git over HTTPS; no GitHub CLI is needed.
4. From then on, ask it to push after each commit, and review the diffs on GitHub when you want a closer look.

Step 6: Debug and review

When something breaks, paste the full error and ask OpenClaw to reproduce the bug and find the cause before it changes anything, instead of trying random fixes. For a hard bug, raise the reasoning effort with /think high if your model supports it. Before you call a feature done, ask for a review of the diff since the last release: what could break, what is untested, and what is unclear.

If a chat gets long and OpenClaw starts losing track, send /compact to summarise the conversation and free up context, or start a fresh chat with /new and point it at the project's PLAN.md.

Larger projects: work in milestones

On a bigger project the limit is not what OpenClaw can write but what it can keep in mind. A chat that runs for hours gets compacted and loses detail, so keep the project's memory in files and commits instead of the conversation.

1. Split the plan into milestones that each end in something you can run and test.
2. Keep the rules in the project's AGENTS.md and the plan in PLAN.md, with the pointer from Step 3 in the workspace file.
3. Finish one milestone per chat: build, test, commit, push.
4. Start the next milestone with /new, then: "Read the plan, check the last commits, and start milestone 2."

Pick a model that can code

The model matters more for code than for chat. Small models handle a single function fine but lose the thread on multi-file changes. Use the strongest model you have access to from your bot's model picker on the dashboard. If you have an Ollama Cloud subscription, save your key on the Ollama Cloud card at API Keys, then choose a model from the Ollama Cloud section of the bot's own picker. The card's "Set as primary model" button switches every running bot on your account, so use the per-bot picker if you only want to change one. On 11 November 2026 Ollama listed coding-capable options such as kimi-k2.7-code, kimi-k3, glm-5.3 and deepseek-v4-pro.

Useful commands

Slash commands work in the dashboard chat and in chat apps connected to your bot, such as Telegram or Discord.

Frequently asked questions

Related guides

• Hermes Agent coding workflow
• Coding workspaces for Claude Code and Codex
• What an OpenClaw agent can do
• Hosted Hermes Agent