description:Use when working in the linkerhand-cpp-sdk repository and you need to quickly understand the project framework, locate the correct API layer, identify model-specific capabilities such as L6/L7/L10/L20/L25, or prepare for fast vibe-coding changes without rereading the whole repo.
---
# LinkerHand SDK Quick Read
Use this skill when the task is to understand, modify, document, or extend this repository efficiently.
## Goal
Build a fast and accurate mental model of the SDK before editing code or writing docs.
## Quick workflow
1. Read the framework entry points first:
-`README.md`
-`CMakeLists.txt`
-`include/Common.h`
-`include/LinkerHandApi.h`
-`include/HandFactory.h`
2. Identify the target model header:
-`include/LinkerHandL6.h`
-`include/LinkerHandL7.h`
-`include/LinkerHandL10.h`
-`include/LinkerHandL20.h`
-`include/LinkerHandL25.h`
-`include/ModbusLinkerHandL10.h`
3. Read `include/IHand.h` to see which methods are truly common and which ones can throw `UnsupportedFeatureException`.
4. Read usage examples:
-`src/main.cpp`
-`examples/toolset_example.cpp`
-`examples/action_group_show_l10.cpp`
5. Read docs only as needed:
-`docs/API-Reference.md`
-`docs/TROUBLESHOOTING.md`
-`docs/FAQ.md`
-`docs/L6-Application-Development-Manual.md`
-`docs/L6-API-Development-Guide.md`
6. If you need a compact structure map, read `references/project-map.md`.
## What to conclude early
Before making claims, answer these points:
- Is the user asking about the public API layer or a model-specific layer?
- Is the capability exposed by `LinkerHandApi`, or only by a concrete hand class?
- Is the behavior visible in headers/docs/examples, or hidden inside the prebuilt `.so`?
- Is the task about SDK usage, repository structure, or extending the SDK itself?
## Repository facts that matter
- The main public entry point is `LinkerHandApi`.
- The factory layer is `HandFactory`.
- Cross-model behavior is defined by `IHand`.
- Model-specific features live in model headers.
- A large part of the implementation is shipped as prebuilt libraries under `lib/x86_64/` and `lib/aarch64/`.
- Tests mostly cover utility and framework pieces, not all device behaviors.
## Working rules
- Prefer `rg --files` and `rg -n` to locate structure and APIs quickly.
- For API claims, trust headers first, examples second, docs third.
- If a behavior is inferred from factory logic or declarations rather than implementation, label it as an inference.
- When documenting or changing L6 behavior, explicitly separate:
- generic API behavior
-`L6Hand`-only behavior
- If a task concerns communication setup, inspect both `HandFactory.h` and the relevant docs before editing.
Use this skill for the RM75 drag-teach trajectory pipeline in the linkerhand checkout.
## Workflow
1. Read `references/workflow.md` before editing code or running commands.
2. Prefer the `RM/` subproject for maintained C++ code.
3. Keep the older `examples/realman_trajectory_*` programs as compatibility demos unless the user explicitly asks to remove or refactor them.
4. Treat synchronized CSV as the primary artifact.
5. Treat `rm_save_trajectory` vendor output as best-effort because the six-dof force drag API does not expose a trajectory-record flag.
## Boundaries
- Put RM SDK calls only in `RM/src/drivers/realman/`.
- Put drag-teach workflow orchestration in `RM/src/core/`.
- Put CSV, directory, and C++ waypoint conversion code in `RM/src/modules/trajectory/`.
- Put human operating instructions in `docs/` or `RM/README.md`.
- Do not run motion or drag-teach commands unless the user explicitly asks and confirms the safety setup.
## Default Safety
Build and validate first. For live drag teach, ensure the workspace is clear, payload is safe, and E-stop is reachable. For TCP replay work, generate C++ waypoint data first; do not jump directly from CSV to live `rm_movel`.
- Do not run live drag teach or replay unless the user explicitly requests it.
- First live run must be unloaded, low-speed/manual, with clear workspace and reachable E-stop.
- Keep CSV as the primary replay/conversion input.
- For TCP path reproduction, use CSV joint values as future IK references or validation data; do not assume TCP-only waypoints uniquely determine RM75 arm posture.