[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M78Z5WWZMYDEXNX384GSGVJS":3,"skill-same:01M78Z5WWZMYDEXNX384GSGVJS":83},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":27,"commitSha":28,"skillDirectory":29,"forksCount":30,"repositoryHtmlUrl":31,"repositoryHomepageUrl":6,"ownerHtmlUrl":32,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":33,"install":34,"resources":46},"01M78Z5WWZMYDEXNX384GSGVJS","extensions-and-services",null,"Extend LeRobot with discoverable policies, processors, hardware plugins, asynchronous inference, transport services, annotation validation, or Hugging Face Jobs without crossing hardware, network, credential, or dataset-safety boundaries.","VectorSpaceLab\u002FAREX-Skill","VectorSpaceLab","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F180637102?v=4","01M7538C5WPSJGWF7KHR4EFZ9F","01M7538C6R2GFP53NPXTCZNBRT",351,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FVectorSpaceLab\u002FAREX-Skill\u002Fblob\u002Fmain\u002Fskills\u002Frepositories\u002Frepo-skills\u002Flerobot\u002Fsub-skills\u002Fextensions-and-services\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: extensions-and-services\ndescription: \"Extend LeRobot with discoverable policies, processors, hardware\n  plugins, asynchronous inference, transport services, annotation validation, or\n  Hugging Face Jobs without crossing hardware, network, credential, or\n  dataset-safety boundaries.\"\ndisable-model-invocation: true\nmetadata:\n  disco-role: operating\nlicense: Apache 2.0\n---\n\n# Extensions and services\n\nUse this skill when the task mentions a custom policy, processor, plugin, package prefix, `lerobot_robot_`, `lerobot_camera_`, `lerobot_teleoperator_`, async inference, a policy server\u002Fclient, gRPC, transport, annotation, an annotation schema, HF Jobs, or a service endpoint.\n\n## Safety and routing\n\n- This skill covers extension seams and **local diagnostics**. It does not replace the dataset, policy, hardware, simulation, or training sub-skills.\n- Route dataset creation, episode\u002Fvideo decoding, language-column editing, and ordinary dataset inspection to the dataset skill; route model architecture\u002Ftraining\u002Fevaluation to the policy skill; route robot motion, camera capture, calibration, teleoperation, and motor access to hardware; route Gym\u002Fenv execution to simulation.\n- Never start a daemon, connect to a robot\u002Fcamera, open a remote endpoint, submit a job, push to the Hub, or send credentials merely to diagnose a configuration.\n- Treat remote bytes as untrusted. The async implementation currently uses pickle for handshake, observations, and actions; use it only between mutually trusted endpoints on a protected network. Do not deserialize arbitrary bytes in a probe.\n\n## Inputs and outputs\n\nInputs are one or more of: a plugin distribution\u002Fpackage name, a config or config fragment, a processor JSON checkpoint, an async server\u002Fclient parameter set, a local annotation staging tree, or a proposed HF Jobs command. Establish the requested route, package extras, device\u002Fbackend, endpoint ownership, credential availability, and whether the user wants a dry-run or an actual launch.\n\nProduce a route decision, a normalized local config, a list of discovered\u002Fregistered types, or a validation report. A successful diagnostic proves only local parsing\u002Fimportability\u002Fschema invariants; it does not prove hardware, network, model download, VLM availability, Hub authorization, or actuation.\n\n## Decision flow\n\n1. **Classify the extension.** Choose plugin discovery, registry\u002Ffactory, processor serialization, async service, annotation, or Jobs. Start with the [extension API](references\u002Fextension-api.md) or the closest route below.\n2. **Check the boundary.** Confirm optional extras and whether the requested operation needs a GPU, vendor SDK, ffmpeg\u002Fvideo backend, HF token, or writable Hub repo. Stop at the first missing gate.\n3. **Inspect before importing.** Run the read-only plugin probe for installed distribution prefixes. Use explicit `discover_packages_path` only when a local plugin package is intentionally supplied. Do not guess a registered `type` from a distribution name.\n4. **Validate local structure.** Use `async_config_check.py` for server\u002Fclient scalar settings and `annotation_config_check.py` for annotation config\u002Fschema. Use `--help` on the real CLI for scoped draccus fields, but do not launch it.\n5. **Resolve collisions and unknowns.** Registry names are global within the process. A duplicate processor-step name raises `ValueError`; an unknown policy\u002Fhardware\u002Fstep type is a registration\u002Fimport problem, not a network problem. Remove or rename the conflicting registration and start a fresh process.\n6. **Only then hand off.** If the user explicitly requests execution, hand the verified config to the relevant focused skill and require its own hardware\u002Fnetwork\u002Fcredential confirmation.\n\n## Extension quick routes\n\n- **Policy:** register a `PreTrainedConfig` subclass with a unique name, make its modeling module expose the corresponding policy class, and provide required feature\u002Fdelta\u002Foptimizer\u002Fscheduler validation. Use the policy factory; do not instantiate a model by guessing a module path.\n- **Processor:** implement `ProcessorStep.__call__` and `transform_features`; use a unique `ProcessorStepRegistry` name. Keep `get_config()` JSON-serializable and use tensor `state_dict()` only for state. Test both data and feature transforms.\n- **Robot\u002Fcamera\u002Fteleoperator:** subclass the corresponding `*Config`, register a unique choice, expose the implementation class using the config class name without the trailing `Config`, and keep vendor imports optional. Factory construction can connect or touch hardware, so diagnostics stop at config\u002Ftype resolution.\n- **Plugin:** an installed distribution whose name starts with an accepted `lerobot_*_` prefix is imported by `register_third_party_plugins()`. Package initialization should register choices; failures are logged and do not abort discovery. For scoped config plugins, `load_plugin()` imports the package and its immediate submodules.\n\n## Async and transport route\n\nThe async route is a two-process gRPC protocol: client calls `Ready`, sends a pickled `RemotePolicyConfig` via `SendPolicyInstructions`, streams chunked pickled `TimedObservation` values through `SendObservations`, and requests pickled `list[TimedAction]` values through `GetActions`. The server loads the requested policy and pre\u002Fpost-processors; the client executes actions locally. Matching host\u002Fport, policy type, checkpoint visibility, device, feature keys, FPS, chunk size, and aggregate function are all required. `services.proto` also declares learner transition RPCs; do not confuse those with async inference.\n\nUse [services](references\u002Fservices.md) for wire details, serialization limits, retries, and a no-daemon mismatch diagnosis. A successful config check must not be reported as a live endpoint check.\n\n## Annotation and Jobs route\n\nAnnotation is a local or HF Jobs VLM workflow, not a harmless metadata edit. It stages module JSONL, validates timestamps\u002Fcolumn routing\u002Fpairs\u002FVQA JSON, then rewrites parquet. Validate a local config and synthetic staging shape before considering a real run. Remote annotation requires a Hub dataset id and HF authentication; a local `root` is not visible in the pod, and output is discarded without `push_to_hub=true`. Training Jobs similarly stage\u002Fresolve configs, forward secrets, and submit cloud work; use the training skill for the actual run.\n\nSee [annotation and Jobs](references\u002Fannotation-and-jobs.md) for the local schema and credential gates. `annotation_config_check.py` never contacts a VLM, Hub, endpoint, or Jobs service.\n\n## Bundled diagnostics\n\n- [`scripts\u002Fplugin_discovery_probe.py`](scripts\u002Fplugin_discovery_probe.py) — lists installed distributions matching LeRobot plugin prefixes without importing them.\n- [`scripts\u002Fasync_config_check.py`](scripts\u002Fasync_config_check.py) — validates server or client scalar configuration from local JSON\u002FYAML or flags; never starts gRPC.\n- [`scripts\u002Fannotation_config_check.py`](scripts\u002Fannotation_config_check.py) — validates local annotation config fields and optional synthetic staging rows; never calls the VLM or Hub.\n\nAll scripts accept `--help`, are safe from arbitrary working directories, and write no files by default. Keep reports outside this skill tree.\n\n## Verification checklist\n\nBefore handing off an extension or service draft:\n\n- confirm the requested package extra and Python\u002Fruntime version are compatible;\n- run the plugin probe and record candidates without importing actuation code;\n- run both valid and invalid async cases, including endpoint syntax and aggregate-name errors;\n- run annotation config validation with a synthetic passing case and an off-frame\u002Forphan\u002FVQA failure;\n- check that every registry name, processor step, artifact, and state tensor has a stable owner;\n- record whether the next step needs model files, GPU, vendor SDK, network, token, Hub write, or physical actuation;\n- keep generated reports and temporary configs out of the runtime skill directory.\n\nA synthetic collision case should place two isolated plugin packages on the import path with the same processor registration and show the second import failing with a duplicate-name error; recovery is to rename\u002Fremove one and retry in a fresh process. A synthetic service mismatch should pair a valid local server config with a client address using a different port and show the checker stopping before any connection. A synthetic annotation case should pass local VQA\u002Ftimestamp\u002Fpair validation while omitting `api_key` or using an unavailable remote target, then stop with the network\u002Fcredential requirement rather than attempting a call.\n\n## Configuration and recovery\n\nUse [configuration](references\u002Fconfiguration.md) for draccus, `ChoiceRegistry`, path-vs-type rules, processor JSON\u002Fstate\u002Fartifact boundaries, and Hub-locality behavior. Use [troubleshooting](references\u002Ftroubleshooting.md) when a type is unknown, a plugin collides, an endpoint is mismatched, a backend is missing, annotation validation fails, or a remote credential is absent.\n\nValidation is complete only when links resolve, scripts pass parser\u002Fhelp checks, local configs pass or fail with actionable errors, and every unresolved hardware\u002Fnetwork\u002Fcredential assumption is recorded. Intentional omissions and known implementation hazards are preserved in the troubleshooting reference.\n\n## Handoff format\n\nReturn a concise record with:\n\n- **Route:** plugin, registry\u002Ffactory, processor, async, annotation, or Jobs;\n- **Inputs:** config source kind, selected type\u002Fname, local-vs-Hub ownership, and requested side effects;\n- **Validated:** exact local checks and their pass\u002Ffail results;\n- **Gates:** missing extra, vendor\u002Fbackend, endpoint, model, credential, Hub write, or actuation gate;\n- **Recovery:** the smallest safe next action, preferably in a fresh process;\n- **Omissions:** behavior not proved because this skill stopped before network, cloud, or hardware.\n\nDo not claim that a plugin is usable because its distribution is listed, that a service is reachable because its address parses, or that an annotation is publishable because its JSON schema passes. Do not duplicate dataset editing, policy training, hardware control, or simulation instructions here; hand those routes to the focused sub-skills.\n","# Extensions and services\n\nUse this skill when the task mentions a custom policy, processor, plugin, package prefix, `lerobot_robot_`, `lerobot_camera_`, `lerobot_teleoperator_`, async inference, a policy server\u002Fclient, gRPC, transport, annotation, an annotation schema, HF Jobs, or a service endpoint.\n\n## Safety and routing\n\n- This skill covers extension seams and **local diagnostics**. It does not replace the dataset, policy, hardware, simulation, or training sub-skills.\n- Route dataset creation, episode\u002Fvideo decoding, language-column editing, and ordinary dataset inspection to the dataset skill; route model architecture\u002Ftraining\u002Fevaluation to the policy skill; route robot motion, camera capture, calibration, teleoperation, and motor access to hardware; route Gym\u002Fenv execution to simulation.\n- Never start a daemon, connect to a robot\u002Fcamera, open a remote endpoint, submit a job, push to the Hub, or send credentials merely to diagnose a configuration.\n- Treat remote bytes as untrusted. The async implementation currently uses pickle for handshake, observations, and actions; use it only between mutually trusted endpoints on a protected network. Do not deserialize arbitrary bytes in a probe.\n\n## Inputs and outputs\n\nInputs are one or more of: a plugin distribution\u002Fpackage name, a config or config fragment, a processor JSON checkpoint, an async server\u002Fclient parameter set, a local annotation staging tree, or a proposed HF Jobs command. Establish the requested route, package extras, device\u002Fbackend, endpoint ownership, credential availability, and whether the user wants a dry-run or an actual launch.\n\nProduce a route decision, a normalized local config, a list of discovered\u002Fregistered types, or a validation report. A successful diagnostic proves only local parsing\u002Fimportability\u002Fschema invariants; it does not prove hardware, network, model download, VLM availability, Hub authorization, or actuation.\n\n## Decision flow\n\n1. **Classify the extension.** Choose plugin discovery, registry\u002Ffactory, processor serialization, async service, annotation, or Jobs. Start with the [extension API](references\u002Fextension-api.md) or the closest route below.\n2. **Check the boundary.** Confirm optional extras and whether the requested operation needs a GPU, vendor SDK, ffmpeg\u002Fvideo backend, HF token, or writable Hub repo. Stop at the first missing gate.\n3. **Inspect before importing.** Run the read-only plugin probe for installed distribution prefixes. Use explicit `discover_packages_path` only when a local plugin package is intentionally supplied. Do not guess a registered `type` from a distribution name.\n4. **Validate local structure.** Use `async_config_check.py` for server\u002Fclient scalar settings and `annotation_config_check.py` for annotation config\u002Fschema. Use `--help` on the real CLI for scoped draccus fields, but do not launch it.\n5. **Resolve collisions and unknowns.** Registry names are global within the process. A duplicate processor-step name raises `ValueError`; an unknown policy\u002Fhardware\u002Fstep type is a registration\u002Fimport problem, not a network problem. Remove or rename the conflicting registration and start a fresh process.\n6. **Only then hand off.** If the user explicitly requests execution, hand the verified config to the relevant focused skill and require its own hardware\u002Fnetwork\u002Fcredential confirmation.\n\n## Extension quick routes\n\n- **Policy:** register a `PreTrainedConfig` subclass with a unique name, make its modeling module expose the corresponding policy class, and provide required feature\u002Fdelta\u002Foptimizer\u002Fscheduler validation. Use the policy factory; do not instantiate a model by guessing a module path.\n- **Processor:** implement `ProcessorStep.__call__` and `transform_features`; use a unique `ProcessorStepRegistry` name. Keep `get_config()` JSON-serializable and use tensor `state_dict()` only for state. Test both data and feature transforms.\n- **Robot\u002Fcamera\u002Fteleoperator:** subclass the corresponding `*Config`, register a unique choice, expose the implementation class using the config class name without the trailing `Config`, and keep vendor imports optional. Factory construction can connect or touch hardware, so diagnostics stop at config\u002Ftype resolution.\n- **Plugin:** an installed distribution whose name starts with an accepted `lerobot_*_` prefix is imported by `register_third_party_plugins()`. Package initialization should register choices; failures are logged and do not abort discovery. For scoped config plugins, `load_plugin()` imports the package and its immediate submodules.\n\n## Async and transport route\n\nThe async route is a two-process gRPC protocol: client calls `Ready`, sends a pickled `RemotePolicyConfig` via `SendPolicyInstructions`, streams chunked pickled `TimedObservation` values through `SendObservations`, and requests pickled `list[TimedAction]` values through `GetActions`. The server loads the requested policy and pre\u002Fpost-processors; the client executes actions locally. Matching host\u002Fport, policy type, checkpoint visibility, device, feature keys, FPS, chunk size, and aggregate function are all required. `services.proto` also declares learner transition RPCs; do not confuse those with async inference.\n\nUse [services](references\u002Fservices.md) for wire details, serialization limits, retries, and a no-daemon mismatch diagnosis. A successful config check must not be reported as a live endpoint check.\n\n## Annotation and Jobs route\n\nAnnotation is a local or HF Jobs VLM workflow, not a harmless metadata edit. It stages module JSONL, validates timestamps\u002Fcolumn routing\u002Fpairs\u002FVQA JSON, then rewrites parquet. Validate a local config and synthetic staging shape before considering a real run. Remote annotation requires a Hub dataset id and HF authentication; a local `root` is not visible in the pod, and output is discarded without `push_to_hub=true`. Training Jobs similarly stage\u002Fresolve configs, forward secrets, and submit cloud work; use the training skill for the actual run.\n\nSee [annotation and Jobs](references\u002Fannotation-and-jobs.md) for the local schema and credential gates. `annotation_config_check.py` never contacts a VLM, Hub, endpoint, or Jobs service.\n\n## Bundled diagnostics\n\n- [`scripts\u002Fplugin_discovery_probe.py`](scripts\u002Fplugin_discovery_probe.py) — lists installed distributions matching LeRobot plugin prefixes without importing them.\n- [`scripts\u002Fasync_config_check.py`](scripts\u002Fasync_config_check.py) — validates server or client scalar configuration from local JSON\u002FYAML or flags; never starts gRPC.\n- [`scripts\u002Fannotation_config_check.py`](scripts\u002Fannotation_config_check.py) — validates local annotation config fields and optional synthetic staging rows; never calls the VLM or Hub.\n\nAll scripts accept `--help`, are safe from arbitrary working directories, and write no files by default. Keep reports outside this skill tree.\n\n## Verification checklist\n\nBefore handing off an extension or service draft:\n\n- confirm the requested package extra and Python\u002Fruntime version are compatible;\n- run the plugin probe and record candidates without importing actuation code;\n- run both valid and invalid async cases, including endpoint syntax and aggregate-name errors;\n- run annotation config validation with a synthetic passing case and an off-frame\u002Forphan\u002FVQA failure;\n- check that every registry name, processor step, artifact, and state tensor has a stable owner;\n- record whether the next step needs model files, GPU, vendor SDK, network, token, Hub write, or physical actuation;\n- keep generated reports and temporary configs out of the runtime skill directory.\n\nA synthetic collision case should place two isolated plugin packages on the import path with the same processor registration and show the second import failing with a duplicate-name error; recovery is to rename\u002Fremove one and retry in a fresh process. A synthetic service mismatch should pair a valid local server config with a client address using a different port and show the checker stopping before any connection. A synthetic annotation case should pass local VQA\u002Ftimestamp\u002Fpair validation while omitting `api_key` or using an unavailable remote target, then stop with the network\u002Fcredential requirement rather than attempting a call.\n\n## Configuration and recovery\n\nUse [configuration](references\u002Fconfiguration.md) for draccus, `ChoiceRegistry`, path-vs-type rules, processor JSON\u002Fstate\u002Fartifact boundaries, and Hub-locality behavior. Use [troubleshooting](references\u002Ftroubleshooting.md) when a type is unknown, a plugin collides, an endpoint is mismatched, a backend is missing, annotation validation fails, or a remote credential is absent.\n\nValidation is complete only when links resolve, scripts pass parser\u002Fhelp checks, local configs pass or fail with actionable errors, and every unresolved hardware\u002Fnetwork\u002Fcredential assumption is recorded. Intentional omissions and known implementation hazards are preserved in the troubleshooting reference.\n\n## Handoff format\n\nReturn a concise record with:\n\n- **Route:** plugin, registry\u002Ffactory, processor, async, annotation, or Jobs;\n- **Inputs:** config source kind, selected type\u002Fname, local-vs-Hub ownership, and requested side effects;\n- **Validated:** exact local checks and their pass\u002Ffail results;\n- **Gates:** missing extra, vendor\u002Fbackend, endpoint, model, credential, Hub write, or actuation gate;\n- **Recovery:** the smallest safe next action, preferably in a fresh process;\n- **Omissions:** behavior not proved because this skill stopped before network, cloud, or hardware.\n\nDo not claim that a plugin is usable because its distribution is listed, that a service is reachable because its address parses, or that an annotation is publishable because its JSON schema passes. Do not duplicate dataset editing, policy training, hardware control, or simulation instructions here; hand those routes to the focused sub-skills.\n",{"name":5,"license":23,"metadata":24,"description":7,"disable-model-invocation":26},"Apache 2.0",{"disco-role":25},"operating",true,"main","ac3fe1afa80fb9a09775ecfb2b6cc3ba850a2db6","skills\u002Frepositories\u002Frepo-skills\u002Flerobot\u002Fsub-skills\u002Fextensions-and-services",27,"https:\u002F\u002Fgithub.com\u002FVectorSpaceLab\u002FAREX-Skill","https:\u002F\u002Fgithub.com\u002FVectorSpaceLab","2026-09-03 10:25:21",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":26},[36,39,42],{"tool":37,"command":38},"npx","npx skills add VectorSpaceLab\u002FAREX-Skill --skill extensions-and-services",{"tool":40,"command":41},"bunx","bunx skills add VectorSpaceLab\u002FAREX-Skill --skill extensions-and-services",{"tool":43,"command":44},"pnpm","pnpm dlx skills add VectorSpaceLab\u002FAREX-Skill --skill extensions-and-services","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FVectorSpaceLab\u002FAREX-Skill\u002Fblob\u002Fmain\u002Fskills\u002Frepositories\u002Frepo-skills\u002Flerobot\u002Fsub-skills\u002Fextensions-and-services\u002FSKILL.md",[47,53,57,61,65,69,75,79],{"path":48,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":51,"sourceHtmlUrl":52},"references\u002Fannotation-and-jobs.md","REFERENCE","参考文档",6111,"https:\u002F\u002Fgithub.com\u002FVectorSpaceLab\u002FAREX-Skill\u002Fblob\u002Fmain\u002Fskills\u002Frepositories\u002Frepo-skills\u002Flerobot\u002Fsub-skills\u002Fextensions-and-services\u002Freferences\u002Fannotation-and-jobs.md",{"path":54,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":55,"sourceHtmlUrl":56},"references\u002Fconfiguration.md",5881,"https:\u002F\u002Fgithub.com\u002FVectorSpaceLab\u002FAREX-Skill\u002Fblob\u002Fmain\u002Fskills\u002Frepositories\u002Frepo-skills\u002Flerobot\u002Fsub-skills\u002Fextensions-and-services\u002Freferences\u002Fconfiguration.md",{"path":58,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":59,"sourceHtmlUrl":60},"references\u002Fextension-api.md",7576,"https:\u002F\u002Fgithub.com\u002FVectorSpaceLab\u002FAREX-Skill\u002Fblob\u002Fmain\u002Fskills\u002Frepositories\u002Frepo-skills\u002Flerobot\u002Fsub-skills\u002Fextensions-and-services\u002Freferences\u002Fextension-api.md",{"path":62,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":63,"sourceHtmlUrl":64},"references\u002Fservices.md",6354,"https:\u002F\u002Fgithub.com\u002FVectorSpaceLab\u002FAREX-Skill\u002Fblob\u002Fmain\u002Fskills\u002Frepositories\u002Frepo-skills\u002Flerobot\u002Fsub-skills\u002Fextensions-and-services\u002Freferences\u002Fservices.md",{"path":66,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":67,"sourceHtmlUrl":68},"references\u002Ftroubleshooting.md",7265,"https:\u002F\u002Fgithub.com\u002FVectorSpaceLab\u002FAREX-Skill\u002Fblob\u002Fmain\u002Fskills\u002Frepositories\u002Frepo-skills\u002Flerobot\u002Fsub-skills\u002Fextensions-and-services\u002Freferences\u002Ftroubleshooting.md",{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"scripts\u002Fannotation_config_check.py","SCRIPT","脚本",15535,"https:\u002F\u002Fgithub.com\u002FVectorSpaceLab\u002FAREX-Skill\u002Fblob\u002Fmain\u002Fskills\u002Frepositories\u002Frepo-skills\u002Flerobot\u002Fsub-skills\u002Fextensions-and-services\u002Fscripts\u002Fannotation_config_check.py",{"path":76,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":77,"sourceHtmlUrl":78},"scripts\u002Fasync_config_check.py",7818,"https:\u002F\u002Fgithub.com\u002FVectorSpaceLab\u002FAREX-Skill\u002Fblob\u002Fmain\u002Fskills\u002Frepositories\u002Frepo-skills\u002Flerobot\u002Fsub-skills\u002Fextensions-and-services\u002Fscripts\u002Fasync_config_check.py",{"path":80,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":81,"sourceHtmlUrl":82},"scripts\u002Fplugin_discovery_probe.py",2848,"https:\u002F\u002Fgithub.com\u002FVectorSpaceLab\u002FAREX-Skill\u002Fblob\u002Fmain\u002Fskills\u002Frepositories\u002Frepo-skills\u002Flerobot\u002Fsub-skills\u002Fextensions-and-services\u002Fscripts\u002Fplugin_discovery_probe.py",[84,91,98,105,112,119],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":18},"01M799NYSH1R3RVAHSM2D88Y84","passnet-triton-opt","Make a single PassNet Triton kernel fast AND numerically faithful: performance model (when a replacement can win at all), block\u002Fgrid\u002Fwarp tuning, autotune policy, launch overhead, and per-op numeric recipes to pass the dtype baseline tolerances. Use when a pass matches and is correct but speedup below expected, or when correctness fails by small numeric margins.","https:\u002F\u002Fgithub.com\u002FVectorSpaceLab\u002FAREX-Skill\u002Fblob\u002Fmain\u002Fskills\u002Ftask-oriented\u002FPassNet\u002Fskills\u002Fpassnet-triton-opt\u002FSKILL.md",[],[],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":18},"01M799NS5APEC0N1FZ7XZVW6BN","passnet-solve","END-TO-END playbook for solving one PassNet sample: analyze the computation graphs, decide the optimization strategy (what to fuse, what to replace, what to leave alone), drive the iteration loop, and maximize the sample score. This is the ENTRY skill — invoke it first for any PassNet optimization task; it tells you when to use passnet-pattern-fusion, passnet-triton-opt and passnet-feedback.","https:\u002F\u002Fgithub.com\u002FVectorSpaceLab\u002FAREX-Skill\u002Fblob\u002Fmain\u002Fskills\u002Ftask-oriented\u002FPassNet\u002Fskills\u002Fpassnet-solve\u002FSKILL.md",[],[],{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":18},"01M799NNY9BKSM21V5R7QVTBJX","passnet-skill","PassNet GPU kernel optimization via compiler passes. Design and implement Triton-based optimization passes, create pass files under .\u002Fpass_dir\u002F, self-evaluate with pass_evaluator, and iterate to maximize GPU speedup.","https:\u002F\u002Fgithub.com\u002FVectorSpaceLab\u002FAREX-Skill\u002Fblob\u002Fmain\u002Fskills\u002Ftask-oriented\u002FPassNet\u002Fskills\u002Fpassnet-skill\u002FSKILL.md",[],[],{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":18},"01M799NHH6NP7Z1RK77KGXAN6S","passnet-pattern-fusion","Author PassNet pass files: write patterns that actually MATCH the FX graph, pick fusion regions (which ops to absorb into one Triton kernel), and structure multi-pass submissions with the mandatory shared-dispatch architecture. Use when creating or fixing pattern()\u002Freplacement_args()\u002Freplacement_func() files, when a pass \"failed to match\", or when deciding how to fuse multiple kernels\u002Fops.","https:\u002F\u002Fgithub.com\u002FVectorSpaceLab\u002FAREX-Skill\u002Fblob\u002Fmain\u002Fskills\u002Ftask-oriented\u002FPassNet\u002Fskills\u002Fpassnet-pattern-fusion\u002FSKILL.md",[],[],{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":18},"01M799ND2J4WNC2PGAZ0A06NDF","passnet-orchestrate","Round\u002Fbatch planning and decision support for PassNet graph optimization. Use for multi-sample triage, worker allocation, eval-budget policy, and post-eval keep\u002Frevert decisions. For solving one concrete sample end to end, use passnet-solve as the entry skill; consult this skill only when you need broader planning or a specific decision gate.","https:\u002F\u002Fgithub.com\u002FVectorSpaceLab\u002FAREX-Skill\u002Fblob\u002Fmain\u002Fskills\u002Ftask-oriented\u002FPassNet\u002Fskills\u002Fpassnet-orchestrate\u002FSKILL.md",[],[],{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":18},"01M799N8SBTMY02ZDG2AZF5ZWE","passnet-feedback","Fast, deterministic feedback for PassNet work: pre-flight pattern\u002Fmatch verification WITHOUT burning a GPU evaluation, per-node bottleneck analysis of a sample's graphs, and eval-log parsing into per-variant status + estimated score + failure classification. Use BEFORE every GPU evaluation (check_pattern), at the START of a sample (analyze_graph), and AFTER every evaluation (parse_eval_log).","https:\u002F\u002Fgithub.com\u002FVectorSpaceLab\u002FAREX-Skill\u002Fblob\u002Fmain\u002Fskills\u002Ftask-oriented\u002FPassNet\u002Fskills\u002Fpassnet-feedback\u002FSKILL.md",[],[]]