#Guidance to abilities

1 messages · Page 1 of 1 (latest)

tepid fernBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

opal idolBOT
#

OpenClaw (aka “Clawd”) is basically a bring-your-own-agent framework: what it can do depends on (1) which tools you’ve enabled, (2) what access you’ve granted (workspace, sandbox, network), and (3) which model you’re running.

What it can do (common capabilities)

Coding tasks

  • Generate code, refactor, add tests, write docs, scaffold new modules/features
  • If shell/file tools are allowed: run builds/tests/linters, edit files, iterate like a real dev loop

Debugging

  • Read stack traces/logs, form hypotheses, propose fixes
  • If it can execute commands: reproduce issues, bisect changes, validate fixes, suggest minimal patches

Project structuring / planning

  • Turn a vague idea into a repo structure (packages, modules, boundaries)
  • Create milestones, issues/task lists, architecture notes, conventions, “definition of done”
  • Write specs/RFCs and keep them in sync with the implementation (if you want)

Automation + “assistant stuff” (depending on your setup)

#
  • Web lookups / browser automation (if enabled)
  • Sending messages to Discord/Telegram/etc, reminders/heartbeats, cron-like routines (if enabled)
  • Interacting with connected devices/nodes (if you paired any)

Docs to skim:

The big limitations (things people trip over)

1) It’s only as “hands-on” as the tools you allow

  • No file access → it can advise, but can’t actually change your repo
  • No exec/shell → it can’t run tests/builds, so debugging is more speculative
  • Sandboxing/workspace rules matter a lot for safety and for “why can’t it see X?”
#

2) Models can be wrong

  • It can hallucinate APIs, misread logs, or propose plausible-but-wrong fixes
  • Tool-calling reliability also depends heavily on the model/provider

3) It doesn’t magically have your context

  • If you don’t paste code/logs or point it at a workspace, it’s guessing
  • Long projects still need you to review decisions, especially security-sensitive ones

4) Not a replacement for human judgment

  • Don’t let it run untrusted code blindly
  • Always review diffs, secrets handling, and anything that touches prod or billing

If you tell me your target use-case (e.g. “I want it to build a React app”, “debug my Python backend”, “plan a SaaS repo structure”), and where you’re running it (local / VPS / Mac app), I can suggest a good “capabilities setup” for that workflow.