wendy-contributing/SKILL.md
Expert guidance on contributing to WendyOS: Yocto builds, agent internals, E2E testing, and system architecture. Use when developers mention: (1) building WendyOS images, (2) meta-wendyos layers or bitbake, (3) wendy-agent development or internals, (4) containerd or nerdctl on WendyOS, (5) E2E tests for wendy-agent, (6) Yocto recipes or bbappend files, (7) mDNS/Avahi service configuration, (8) device identity or UUID generation.
npx skillsauth add wendylabsinc/claude-skills wendy-contributingInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
This skill covers internal development and contribution to WendyOS itself, including building OS images, understanding agent architecture, and running E2E tests.
WendyOS is an Embedded Linux operating system for edge computing built with Yocto. It supports:
The wendy-agent is a container daemon (similar to dockerd/containerd):
wendy run, not pulled from Docker Hubdocker pull equivalent - apps are deployed from sourceWendyOS images are built with Yocto. Three meta layers exist:
| Layer | Target | Image |
|-------|--------|-------|
| meta-wendyos-jetson | NVIDIA Jetson | edgeos-image |
| meta-wendyos-virtual | ARM64 VM | edgeos-vm-image |
| meta-wendyos-rpi | Raspberry Pi 4/5 | edgeos-rpi-image |
Quick build (any layer):
cd meta-wendyos-<target>
./bootstrap.sh
source ./repos/poky/oe-init-build-env build
bitbake <image-name>
For macOS, use the Docker build environment:
cd docker && ./docker-util.sh shell
See references/yocto-meta-layers.md for detailed Yocto configuration.
The wendy-agent repository includes an E2E test suite in E2ETests/.
# Start the VM
cd meta-wendyos-virtual
./scripts/setup-dev-vm.sh create && ./scripts/setup-dev-vm.sh start
# Deploy a test app first (required for container tests)
cd wendy-agent/Examples/HelloWorld
wendy run --json --device localhost:50051 # --json for non-interactive output
# Run E2E tests with fast path (CRITICAL for performance)
cd wendy-agent/E2ETests
E2E_USE_EXISTING_VM=true E2E_VM_PATH=/path/to/meta-wendyos-virtual swift test
Important: Always set E2E_USE_EXISTING_VM=true when the VM is already running. This skips shell script checks and reduces test time from ~5s/test to ~0.01s/test.
Tip: Use --json flag on all wendy commands for quick JSON responses without interactive polling.
.serialized trait on test suites to avoid VM race conditionsE2E_USE_EXISTING_VM=true to skip redundant VM status checksIssue.record() for expected failures (like WiFi in VM) - it counts as failureGitHub-hosted runners don't support nested virtualization. Use self-hosted runners or run E2E tests locally.
| Suite | Tests | Time | Notes | |-------|-------|------|-------| | Device Connection | 7 | ~0.07s | gRPC connectivity | | Container Deployment | 6 | ~0.06s | Container lifecycle | | WiFi Operations | 4 | ~0.04s | Graceful failures in VM | | Hardware Capabilities | 4 | ~0.07s | Device enumeration | | Device Discovery | 4 | ~21s | mDNS (slow by design) |
For debugging, container runtime details (containerd/nerdctl), mDNS discovery, device identity, and common pitfalls, see references/system-internals.md.
For Raspberry Pi specific configuration (serial console, flashing, partition layout), see references/raspberry-pi.md.
Load these files as needed for specific topics:
references/yocto-meta-layers.md - Yocto layer structure, build configuration, partition layouts, Docker build environment, common issuesreferences/system-internals.md - containerd runtime, containerd-registry, device identity, mDNS configuration, Lima VM development, offline image bundlingreferences/raspberry-pi.md - RPi machine configuration, serial console, flashing images, partition layoutdevelopment
Expert guidance on Swift best practices, patterns, and implementation. Use when developers mention: (1) Swift configuration or environment variables, (2) swift-log or logging patterns, (3) OpenTelemetry or swift-otel, (4) Swift Testing framework or @Test macro, (5) Foundation avoidance or cross-platform Swift, (6) platform-specific code organization, (7) Span or memory safety patterns, (8) non-copyable types (~Copyable), (9) API design patterns or access modifiers.
tools
Expert guidance on building and deploying apps to WendyOS edge devices. Use when developers mention: (1) Wendy or WendyOS, (2) wendy CLI commands, (3) wendy.json or entitlements, (4) deploying apps to edge devices, (5) remote debugging Swift on ARM64, (6) NVIDIA Jetson or Raspberry Pi apps, (7) cross-compiling Swift for ARM64.
development
Curated Swift package ecosystem for WendyOS and Linux. Use when developers mention: (1) Swift packages for Linux or ARM64/AMD64, (2) choosing a Swift library, (3) Swift Package Index, (4) swiftpackageindex.com, (5) what Swift library to use, (6) Swift on WendyOS dependencies, (7) edge computing Swift libraries.
development
Expert guidance on building WASM apps for Wendy Lite MCU firmware on ESP32-C6. Use when developers mention: (1) Wendy Lite or wendy-lite, (2) WASM apps on ESP32 or microcontrollers, (3) WendyLite Swift package or import WendyLite, (4) building C/Rust/Swift/Zig apps for ESP32, (5) WAMR runtime on embedded devices, (6) GPIO/I2C/SPI/UART/NeoPixel from WASM, (7) Embedded Swift on WASM or wasm32-none-none-wasm, (8) BLE provisioning on ESP32-C6, (9) uploading WASM binaries to MCU, (10) TLS/networking on ESP32 from Swift.