// Discover how a robot is actually used by reading its deployed guide and SDK reference before writing code. Use when starting robot work, when the API is unclear, when a new robot is added, or when OpenClaw must determine the real robot usage pattern instead of guessing.
External services and backend capabilities for AbotClaw robots — vision APIs, VLM/LLM endpoints, planners, speech services, grasping backends, and client SDKs. Use when a robot skill needs an external service, when checking what backend tools already exist, when debugging service reachability, or when deciding whether to build locally versus call a service.
Bundle an AbotClaw robot skill and its dependencies into a single executable Python file or portable submission artifact. Use when preparing robot code for execution environments that want one file, when flattening dependency chains, or when packaging a skill for deployment or review.
SpatialMemoryHub-based robot memory querying, writing, and retrieval for AbotClaw. Use when the agent needs to store or retrieve object memory, place memory, keyframe memory, or semantic frame memory; when checking whether a memory service is running; when using robot SDK camera frames to perform memory ingestion or memory-guided retrieval; or when grounding robot tasks in prior visual/spatial experience.
Use a deployed VLAC-style vision-language-action critic service to evaluate task progress, compare current observations against a reference image, and judge task completion from robot camera frames. Use when the agent needs external progress supervision, completion verification, failure detection, or image-based task-state comparison for Piper, Unitree G1, or Unitree Go2.
Robot connection and reachability guidance for the AbotClaw fleet. Use when identifying the correct robot base URL, auth method, health check, safest first connectivity test, or when debugging why Piper, Unitree G1, or Unitree Go2 cannot be reached.
Hardware roles, embodiment boundaries, and task-fit guidance for Piper, Unitree G1, and Unitree Go2. Use when deciding which robot should handle a task, when reasoning about embodiment constraints, or when documenting robot-specific assumptions in a skill.
| name | abotclaw-sdk-discovery |
| description | Discover how a robot is actually used by reading its deployed guide and SDK reference before writing code. Use when starting robot work, when the API is unclear, when a new robot is added, or when OpenClaw must determine the real robot usage pattern instead of guessing. |
This skill owns one question:
How should OpenClaw discover the real usage pattern of a robot before writing code?
This skill is the single place for:
Other files should reference this skill instead of duplicating SDK discovery instructions.
For AbotClaw, discovery should start from known service and robot configuration, not from broad local searching.
Use this order:
service.mdROBOT.mdcurl -s -L <ROBOT_BASE_URL>/docs/guide/html
curl -s -L <ROBOT_BASE_URL>/code/sdk/markdown
If the deployment exposes a health endpoint, check it before deeper calls:
curl -s <ROBOT_BASE_URL>/health
Before writing robot code, determine:
Before writing code, summarize the real usage pattern in plain terms.
A good summary should answer:
Only use broader fallback sources when the guide or SDK reference is missing or clearly incomplete.
Fallback sources may include:
Do not treat those as the default path.
Do not invent methods because they sound plausible. If the deployed docs do not show a method, treat it as unknown until confirmed.