菜单
Add or maintain libcrafter lab provider adapters, capability contracts, provider matrix tests, and documentation for substrate-independent oracle and probe execution.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | lab-provider |
| description | Add or maintain libcrafter lab provider adapters, capability contracts, provider matrix tests, and documentation for substrate-independent oracle and probe execution. |
Use this skill when adding, changing, or reviewing a provider adapter under
tools/lab/engine/providers/. A lab provider owns substrate mechanics only:
planning roles, exposing capabilities, creating endpoints, normalizing endpoint
manifests, validating sessions, collecting artifacts, and cleanup.
Oracle and probe workload semantics must stay outside lab. The provider should not know oracle packet cases or probe service behavior.
Every lab provider must implement the adapter protocol in
tools/lab/engine/providers/base.py and be registered through the lab provider
registry. Keep these contracts provider-neutral:
Capability names should describe substrate behavior, such as IPv4 unicast, controlled services, provider MAC knowledge, broadcast support, and controlled router support. Workload-specific capability derivation belongs in oracle or probe boundary modules.
Provider adapters should report coarse appliance runtime profiles rather than
protocol-specific execution promises. Use wan-raw, lan-raw, whad-serial,
or dot11-monitor when the provider can place that role, and keep host or VM
preparation details such as Docker readiness, USB passthrough, serial access,
monitor-mode interfaces, and artifact roots in provider or endpoint metadata.
Prepared dongle VMs should be exposed through persistent asset leases so
multiple agent sessions do not use the same hardware concurrently.
For provider changes, run focused tests first, then the matrix:
python3 -m unittest tools.lab.tests.test_provider_registrypython3 -m unittest tools.lab.tests.test_provider_matrixtools/lab/tests/Dry-run behavior must be deterministic and must not create infrastructure. Live behavior must use explicit confirmation and best-effort cleanup on every failure path.
Update provider docs when the provider contract, prerequisites, credentials,
capabilities, or artifact shape changes. Keep agent operating guidance in
.agents/docs/ or repo-local skills, and user-facing tool documentation in
docs/ or the relevant tool README.
Provision and use one disposable remote endpoint provider target for libcrafter packet work. Use for single-endpoint raw sends, captures, debugging, artifact collection, or endpoint teardown; use lab-session for coordinated multi-endpoint oracle/probe workflows.
Provision, use, collect, and tear down multi-endpoint libcrafter lab sessions across Hetzner, QEMU, VirtualBox, and future lab providers. Use when oracle, probe, or generated tools need provider-backed packet work that must be independent of the developer machine.
Add or run libcrafter packet behavior validation through oracle specs, backend adapters, offline checks, pcap checks, live checks, and artifacts. Use when packet behavior changes need validation coverage.
Open, update, title, review, or prepare libcrafter pull requests so commits are ready for rebase-and-fast-forward landing and required validation is documented.
Use ignored .scratch workspaces for experiments, disposable prototypes, network probes, QEMU or dongle labs, generated exploratory code, and any task where the user asks to make a scratch folder or wants code/scripts that should not be committed until promoted.
Create, amend, reword, split, squash, or prepare libcrafter commits with the repository's Conventional Commits policy and scoped staging discipline.