wao 0.41.3 → 0.41.5

package/esm/workspace/.claude/skills/deploy/SKILL.md

@@ -1,85 +0,0 @@
----
-name: deploy
-description: "Deploy AOS scripts to AO testnet, local HyperBEAM, or remote HyperBEAM. Use when user says 'deploy', 'ship it', 'push to mainnet', or 'go live'. Not for local testing — use /test-hb."
-argument-hint: "[--mainnet|--local-hb] [--lua] [lua-file ...]"
-disable-model-invocation: true
-allowed-tools: Bash, Read
----
-
-Deploy AOS Lua scripts.
-
-## Examples
-
-```
-/deploy src/counter.lua                    # deploy to testnet
-/deploy --mainnet src/counter.lua          # deploy to production HyperBEAM
-/deploy --local-hb --lua src/counter.lua   # deploy to local HB in Lua mode
-```
-
-## Steps
-
-1. Run the test suite and abort if any fail:
-
-```bash
-yarn test 2>&1
-```
-
-If tests fail, stop and report. Do NOT deploy with failing tests.
-
-2. Confirm with the user before deploying:
-   - Show which scripts will be deployed
-   - Show the target: testnet (default), `--mainnet` (remote HB), or `--local-hb` (local HB)
-   - If `$ARGUMENTS` is provided, pass them through to the deploy script
-   - If no file arguments, all `src/*.lua` files will be deployed
-   - Ask for confirmation
-
-3. Deploy:
-
-```bash
-# Testnet (default)
-yarn deploy
-yarn deploy src/counter.lua
-
-# Remote HyperBEAM (production — uses push-1.forward.computer)
-yarn deploy --mainnet
-yarn deploy --mainnet src/counter.lua
-
-# Local HyperBEAM (development)
-yarn deploy --local-hb
-yarn deploy --local-hb src/counter.lua
-
-# Lua mode (any target)
-yarn deploy --mainnet --lua
-yarn deploy --local-hb --lua
-
-# Custom node
-yarn deploy --node https://push-3.forward.computer src/counter.lua
-```
-
-The script automatically:
-- Finds the wallet from `.env.hyperbeam` CWD or `.wallet.json`
-- Deploys each script and prints its process ID
-- Reports success/failure for each file
-
-4. Report the process IDs from the output.
-
-## Important
-
-- **Remote HB**: Uses `push-1.forward.computer` (NOT `push.forward.computer` which is push-only with no compute)
-- **Local HB**: Requires HyperBEAM running at localhost:10001
-- **Lua mode**: Faster but no `receive()` support — use `msg.reply()` pattern
-- **Wallet**: Generate with `yarn keygen` if not present
-
-## Troubleshooting
-
-### MU 504 error on testnet
-- AO testnet MU can be flaky — retry after 30 seconds
-- Switch to `--mainnet` for reliable deployment
-
-### "Wallet not found"
-- Generate with `yarn keygen`
-- Or check `.env.hyperbeam` CWD for existing wallet
-
-### Process ID returned but process unreachable
-- Testnet processes may take 10-30s to become available
-- For HyperBEAM, verify the node is still running

package/esm/workspace/.claude/skills/dev/SKILL.md

@@ -1,32 +0,0 @@
----
-name: dev
-description: "Start the Vite dev server for frontend development. Use when user says 'start the frontend', 'run dev server', or 'open the app'. Not for running tests — use /test-e2e for Playwright."
-disable-model-invocation: true
-allowed-tools: Bash, Read
----
-
-Start the Vite dev server for frontend development.
-
-## Steps
-
-1. Check if the `frontend/` directory exists:
-
-```bash
-test -d frontend && echo "Frontend found" || echo "ERROR: No frontend/ directory. Run npx wao create with frontend option to scaffold one."
-```
-
-2. If `frontend/` doesn't exist, stop and tell the user to re-scaffold with the frontend option.
-
-3. Install frontend dependencies if needed:
-
-```bash
-cd frontend && npm install
-```
-
-4. Start the Vite dev server:
-
-```bash
-cd frontend && npm run dev
-```
-
-5. Report the local URL (usually http://localhost:5173).

package/esm/workspace/.claude/skills/plan/SKILL.md

@@ -1,176 +0,0 @@
----
-name: plan
-description: "Plan a feature before building. Writes plan.md and tasks.json so any agent can pick up the work. Use when starting a new feature, user says 'plan this', 'design this', or 'what should we build'. Not for modifying existing plans — edit plan.md directly."
-argument-hint: "<feature-description>"
-disable-model-invocation: true
-allowed-tools: Read, Write, Grep, Glob
----
-
-Plan a feature before building it. The plan and tasks are written to files so any Claude session can pick up and execute them.
-
-## Performance Notes
-- Take your time researching patterns and edge cases
-- Quality of the plan determines quality of the build — a thorough plan saves iteration cycles
-- Consider all edge cases before writing tasks.json — it's cheaper to plan than to rebuild
-
-## Steps
-
-1. Read the user's feature description from `$ARGUMENTS`.
-
-2. **Prompt the user** to choose which components to build. Ask them to select one or more:
-   - **AOS Lua scripts** — Lua scripts running on AOS processes (src/*.lua)
-   - **Custom Modules** — WASM64 (Rust) or standalone Lua modules (custom-wasm/ or custom-lua/)
-   - **HyperBEAM devices** — custom Erlang device modules (HyperBEAM/src/*.erl)
-   - **Frontend** — Vite + React browser app with wao/web (frontend/)
-
-   Wait for the user's answer before proceeding. Only generate tasks for the selected components.
-
-3. Read the relevant docs for the selected components:
-   - AOS scripts → `docs/aos-lua.md`
-   - Custom Modules (Lua) → `docs/docs/pages/tutorials/custom-lua.mdx`
-   - Custom Modules (WASM64) → `docs/docs/pages/tutorials/rust-wasm64.mdx`
-   - HyperBEAM devices → `docs/hyperbeam-dev.md` and `docs/hyperbeam-devices.md`
-   - JS/SDK → `docs/wao-sdk.md`
-   - Frontend → `docs/wao-sdk.md` (browser section)
-
-4. Design the feature: files, AOS scripts/devices, edge cases, test scenarios.
-
-5. Write `plan.md` at the project root:
-
-```markdown
-# Plan: {feature name}
-
-## Overview
-{1-2 sentence summary}
-
-## Components
-- [ ] AOS: {yes/no — list AOS scripts}
-- [ ] Custom Modules: {yes/no — list modules, specify Lua or WASM64}
-- [ ] Device: {yes/no — list devices}
-- [ ] Frontend: {yes/no — list pages/components}
-
-## AOS Scripts
-| Script | Action | Input Tags | State | Reply |
-|---------|--------|------------|-------|-------|
-
-## Devices
-| Device | Module | Exports | Description |
-|--------|--------|---------|-------------|
-
-## Edge Cases
-1. ...
-
-## Status: PENDING APPROVAL
-```
-
-6. Write `tasks.json` at the project root. This is a JSON file so any agent can precisely parse task status. Tasks follow a strict build order based on what components are included. Pick the applicable task templates:
-
-```json
-{
-  "feature": "{feature name}",
-  "tracks": ["aos"],
-  "current_step": 0,
-  "tasks": [
-    {
-      "id": 1,
-      "name": "Build AOS scripts",
-      "type": "aos",
-      "skill": "/build-aos",
-      "status": "pending",
-      "files": ["src/{name}.lua"],
-      "details": "{script names, actions, input tags, state, reply format, input validation}",
-      "done_when": "AOS scripts written with all edge cases handled"
-    },
-    {
-      "id": 2,
-      "name": "Write in-memory AOS tests",
-      "type": "aos-test",
-      "skill": "/build-aos",
-      "status": "pending",
-      "files": ["test/{name}.test.js"],
-      "details": "{test scenarios — happy path, error paths, multi-user, boundaries}",
-      "done_when": "yarn test test/{name}.test.js — all pass"
-    },
-    {
-      "id": 3,
-      "name": "Write AOS HyperBEAM integration tests",
-      "type": "aos-integration",
-      "skill": "/test-hb",
-      "status": "pending",
-      "files": ["test/hyperbeam.test.js"],
-      "details": "{deploy AOS scripts on real HyperBEAM via genesis-wasm, test through HTTP}",
-      "done_when": "yarn test test/hyperbeam.test.js — all pass"
-    }
-  ]
-}
-```
-
-**Root-level fields**:
-- `"tracks"` — array of selected build tracks: `"aos"`, `"module"`, `"device"`, `"frontend"` (only the ones the user chose)
-- `"current_step"` — set to `0` initially; `/build` updates this as it progresses through tasks
-
-**Every task must include `"skill"`** — the slash command that handles it. This is how `/build` dispatches work:
-
-| Task type | Skill |
-|-----------|-------|
-| `aos` | `/build-aos` |
-| `aos-test` | `/build-aos` |
-| `aos-integration` | `/test-hb` |
-| `module-lua` | `/build-module` |
-| `module-wasm` | `/build-module` |
-| `module-test` | `/build-module` |
-| `device` | `/build-device` (eunit tests inline — same file) |
-| `device-integration` | `/test-device` |
-| `frontend` | `/build-frontend` |
-| `frontend-test` | `/build-frontend` |
-| `frontend-integration` | `/test-e2e` |
-| `readme` | `/readme` |
-| `validate` | `/validate` |
-
-**Custom Module tasks** (if building custom WASM64 or Lua modules) — add `"module"` to `tracks` array and add these to `tasks`:
-- For Lua: `{ "type": "module-lua", "skill": "/build-module", "files": ["custom-lua/{name}.lua"], "done_when": "module written with compute function" }`
-- For WASM64: `{ "type": "module-wasm", "skill": "/build-module", "files": ["custom-wasm/src/lib.rs"], "done_when": "cargo build succeeds, .wasm file produced" }`
-- Tests: `{ "type": "module-test", "skill": "/build-module", "files": ["test/{name}-module.test.js"], "done_when": "yarn test test/{name}-module.test.js — all pass" }`
-
-**Device tasks** (if building Erlang devices) — add `"device"` to `tracks` array and add these to `tasks`:
-- `{ "type": "device", "skill": "/build-device", "files": ["HyperBEAM/src/dev_{name}.erl"], "done_when": "rebar3 compile + eunit — all pass" }`
-  - **HyperBEAM convention**: device source and eunit tests live in the same `.erl` file using `-ifdef(TEST).` guards. Do NOT create separate test files in `HyperBEAM/test/`.
-- `{ "type": "device-integration", "skill": "/test-device", "files": ["test/{name}-device.test.js"], "done_when": "yarn test test/{name}-device.test.js — all pass" }`
-
-**Frontend tasks** (if building frontend) — add `"frontend"` to `tracks` array and add these to `tasks`:
-- `{ "type": "frontend", "skill": "/build-frontend", "files": ["frontend/src/{components}"], "done_when": "components render, connect to AO processes" }`
-- `{ "type": "frontend-test", "skill": "/build-frontend", "files": ["frontend/test/{name}.test.jsx"], "done_when": "cd frontend && npm run test:unit — all pass" }`
-- `{ "type": "frontend-integration", "skill": "/test-e2e", "files": ["frontend/e2e/{name}.spec.js"], "done_when": "cd frontend && npm run test:e2e — all pass" }`
-
-**README task** — add after all build/test tasks, before validate:
-- `{ "type": "readme", "skill": "/readme", "done_when": "README.md written with architecture, setup, and usage" }`
-
-**Final validation** — always the last task:
-- `{ "type": "validate", "skill": "/validate", "done_when": "overall PASS" }`
-
-### IMPORTANT: Replace all placeholders with actual names
-
-The templates above use `{name}` as a placeholder. When writing `tasks.json`, replace ALL placeholders with the actual file names from the plan. For example:
-- `"files": ["src/{name}.lua"]` → `"files": ["src/token.lua", "src/registry.lua"]`
-- `"files": ["test/{name}.test.js"]` → `"files": ["test/token.test.js", "test/registry.test.js"]`
-- `"done_when": "yarn test test/{name}.test.js — all pass"` → `"done_when": "yarn test test/token.test.js test/registry.test.js — all pass"`
-
-The `files` array must list every actual file the task will create. The `done_when` must reference the actual test commands. Never leave `{name}` as a literal string in the output.
-
-### Task ordering rules
-
-The build order matters. Within each component:
-- **AOS**: AOS scripts → unit tests → integration tests
-- **Custom Modules**: module source → HyperBEAM integration tests
-- **Device**: Erlang module → eunit → integration tests
-- **Frontend**: components → vitest → Playwright
-
-Cross-component: AOS, Custom Modules, and Device can be built in parallel. Frontend depends on AOS/Device/Module being done (it calls them). Final validation is always last.
-
-### Task numbering
-
-Number task `id` sequentially starting from 1. Only include tasks for selected components. A pure AOS project might have 3 tasks + validate. A full project with all four components might have 12+ tasks.
-
-7. Each task must be self-contained — a new agent reading only `plan.md` and `tasks.json` should be able to execute any task without additional context.
-
-8. Show the plan to the user and wait for approval. After approval, update `plan.md` status to `APPROVED`.

package/esm/workspace/.claude/skills/readme/SKILL.md

@@ -1,186 +0,0 @@
----
-name: readme
-description: "Generate a comprehensive README.md from the project's plan, code, and tests. Use when user says 'write the readme', 'document this', or 'generate docs'. Not for plan.md — use /plan."
-disable-model-invocation: true
-allowed-tools: Read, Write, Glob, Grep
----
-
-Generate a comprehensive README.md that explains the project thoroughly — what it does, why it exists, how it works, and complete API references for every script, device, and module.
-
-## Performance Notes
-- Read every source file before writing — the README must be accurate, not guessed
-- Include real code examples extracted from test files
-- Document every handler/action, not just the main ones
-
-## Steps
-
-1. Read `plan.md` for the feature overview, architecture decisions, and edge cases.
-
-2. Read **every** AOS script in `src/*.lua`. For each script, extract:
-   - Purpose and what problem it solves
-   - Every `Handlers.add()` — action name, expected tags, return data, error cases
-   - State shape (what globals/tables the script maintains)
-   - Interactions with other scripts (cross-process messages)
-
-3. Read **every** test file in `test/*.test.js`. Extract:
-   - Real usage examples (deploy, message, dry-run patterns)
-   - Edge cases being tested (what fails, what's validated)
-   - Multi-user scenarios
-
-4. If `custom-lua/` or `custom-wasm/` exist, read the module source:
-   - What the module does (compute function, state handling)
-   - Input/output format
-   - How it differs from standard AOS
-
-5. If `HyperBEAM/src/dev_*.erl` files exist, read each device:
-   - Device purpose and when to use it
-   - Exported functions and their signatures
-   - State structure and lifecycle
-   - HTTP endpoints it exposes
-
-6. If `frontend/src/` exists, read key components and hooks:
-   - What the app does from a user perspective
-   - How it connects to AOS (which hooks, which actions)
-   - Wallet integration (ArConnect)
-
-7. Read `package.json` for available scripts and dependencies.
-
-8. Read `scripts/deploy.js` for deployment details.
-
-9. **Write `README.md`** at the project root with ALL of these sections:
-
-```markdown
-# {Project Name}
-
-{2-3 sentence description: what it does, what platform it runs on, who it's for}
-
-## Overview
-
-{Expanded explanation — what problem does this solve? What are the key features?
-List each major capability as a bullet point with a brief explanation.}
-
-## How It Works
-
-{Explain the architecture in plain language:
-- What happens when a user interacts with the app
-- How AOS scripts process messages
-- How state is maintained
-- If HyperBEAM: how devices fit in the pipeline
-- If frontend: how the browser connects to AOS}
-
-## Project Structure
-
-```
-{file tree with inline comments for every important file}
-```
-
-## Prerequisites
-
-- Node.js 20+
-- Arweave wallet (`yarn keygen` to generate)
-- {Erlang/OTP 27+ if devices}
-- {ArConnect browser extension if frontend}
-
-## Setup
-
-```bash
-yarn install
-yarn keygen
-```
-
-## AOS Script Reference
-
-### {script_name}.lua
-
-{What this script does and why it exists}
-
-**State**: {describe the tables/globals maintained}
-
-| Action | Tags | Returns | Description |
-|--------|------|---------|-------------|
-| {action} | {required tags} | {return data} | {what it does} |
-
-**Example** (from tests):
-```js
-{real code example extracted from test file}
-```
-
-**Edge Cases**:
-- {what happens on invalid input}
-- {what happens on insufficient balance, etc.}
-
-{repeat for every script}
-
-## Device Reference (if applicable)
-
-### dev_{name}.erl
-
-{What this device does}
-
-| Function | Input | Output | Description |
-|----------|-------|--------|-------------|
-| {function} | {params} | {return} | {what it does} |
-
-{repeat for every device}
-
-## Custom Module Reference (if applicable)
-
-### {module_name}
-
-{What this module does, how it differs from standard AOS}
-
-## Frontend (if applicable)
-
-{What the app looks like, what users can do}
-
-### Components
-- {component} — {what it renders}
-
-### Hooks
-- {hook} — {what state it manages}
-
-## Testing
-
-```bash
-yarn test test/aos.test.js          # in-memory AOS (fast)
-yarn test test/{script}.test.js     # specific script tests
-yarn test test/hyperbeam.test.js    # HyperBEAM integration
-cd frontend && npm run test:unit    # frontend vitest
-cd frontend && npm run test:e2e     # Playwright E2E
-```
-
-## Deploy
-
-```bash
-yarn keygen                        # generate wallet (first time only)
-yarn deploy                        # all scripts to AO testnet
-yarn deploy src/{script}.lua       # single script
-yarn deploy --local-hb             # local HyperBEAM
-yarn deploy --mainnet              # remote HyperBEAM (production)
-```
-
-### How Deploy Works
-
-{Explain: reads src/*.lua, spawns a process per file.
-On testnet: Eval message. On HyperBEAM: ao.deploy().
-Each script gets its own process ID printed to console.}
-
-### Verify
-
-- [aolink](https://aolink.ar.io/#/entity/{PROCESS_ID}) — inspect AOS process
-- [lunar](https://lunar.ar.io/#/process/{PROCESS_ID}) — inspect HyperBEAM process
-
-## Built With
-
-- [WAO](https://docs.wao.eco) — SDK for AO and HyperBEAM
-- [AOS](https://ao.arweave.dev) — Lua processes on the AO computer
-{add others as relevant}
-```
-
-10. After writing, re-read the README and verify:
-    - Every AOS action from every script is documented
-    - Every device function is documented
-    - Code examples are real (from test files), not made up
-    - Edge cases are mentioned
-
-11. Update the task status to `"done"` in `tasks.json`.

package/esm/workspace/.claude/skills/report/SKILL.md

@@ -1,49 +0,0 @@
----
-name: report
-description: "Report progress on the current plan. Reads plan.md and tasks.json, shows status of each task and overall progress. Use when user says 'show progress', 'where are we', 'status', or 'what's done'. Not for running tests — use /validate."
-disable-model-invocation: true
-allowed-tools: Read, Bash, Grep, Glob
----
-
-Report the current progress of the build plan.
-
-## Steps
-
-1. Check if `plan.md` and `tasks.json` exist. If not, report "No active plan. Run /plan first."
-
-2. Read `plan.md` for the feature name and components.
-
-3. Read `tasks.json` and count tasks by status:
-   - **done**: completed tasks
-   - **in_progress**: currently being worked on
-   - **pending**: not started yet
-
-4. For each task, show a one-line summary:
-
-```
-## Progress: {feature name}
-
-  ✔ Task 1: Build AOS Lua handlers
-  ✔ Task 2: Write in-memory AOS tests
-  ▶ Task 3: Write AOS HyperBEAM integration tests
-  · Task 4: Build frontend components
-  · Task 5: Write frontend vitest tests
-  · Task 6: Write frontend Playwright integration tests
-  · Task 7: Validate all gates
-
-Progress: 2/7 done, 1 in progress
-
-Components:
-  AOS:      ██████░░░░ tests passing
-  Device:   ░░░░░░░░░░ not started
-  Frontend: ░░░░░░░░░░ not started
-```
-
-5. If any task is `in_progress`, run a quick check on its "done when" condition:
-   - aos-test: run `yarn test` and report pass/fail count
-   - device: run `rebar3 eunit --module=dev_{name}` and report (eunit tests are inline)
-   - module-test: run `yarn test test/{name}-module.test.js` and report
-   - frontend-test: run `cd frontend && npm run test:unit` and report
-   - For other types, just report the status
-
-6. Report any blockers or issues found.

package/esm/workspace/.claude/skills/team/SKILL.md

@@ -1,101 +0,0 @@
----
-name: team
-description: "Set up an agent team for parallel WAO development. Creates coordinated teammates for building features, researching patterns, debugging, or cross-layer work. Use when user says 'work in parallel', 'split the work', 'team up', or 'use multiple agents'."
-argument-hint: "<workflow>"
-disable-model-invocation: true
----
-
-Set up an agent team for parallel WAO development.
-
-The argument `$ARGUMENTS` describes the workflow. Common workflows:
-
-## Examples
-
-```
-/team build      # parallel feature development
-/team debug      # competing hypothesis debugging
-/team device     # cross-layer Erlang + JS development
-/team research   # one researches docs, another implements
-/team module     # custom module development (WASM + Lua)
-```
-
-## Workflows
-
-### `build` — Parallel Feature Development
-
-Create an agent team with teammates that own separate files:
-- **Lua teammate**: builds AOS scripts in `src/`, reads `docs/aos-lua.md` first
-- **Test teammate**: writes tests in `test/`, reads `docs/wao-sdk.md` first
-- **Integration teammate**: verifies everything works together, runs `yarn test`
-
-Each teammate should own distinct files to avoid conflicts. The Lua teammate never edits test files, the test teammate never edits Lua files.
-
-Require plan approval before teammates start implementing.
-
-**File ownership per teammate:**
-- Lua: `src/*.lua` only
-- Test: `test/*.test.js` only
-- Integration: runs `yarn test`, reports results, doesn't edit files
-
-**Acceptance criteria per task:**
-- Lua: AOS script compiles, follows patterns from `docs/aos-lua.md`
-- Test: all assertions pass when run with `yarn test test/{file}.test.js`
-- Integration: full `yarn test` passes with no regressions
-
-### `research` — Research and Build
-
-Create an agent team:
-- **Researcher**: reads the relevant docs (`docs/aos-lua.md`, `docs/wao-sdk.md`, `docs/hyperbeam-devices.md`) and reports patterns, gotchas, and examples back to the team
-- **Builder**: implements the feature based on the researcher's findings
-- **Reviewer**: reviews the implementation for correctness and WAO best practices
-
-### `debug` — Competing Hypotheses
-
-Create an agent team with 3-4 teammates that each investigate a different hypothesis:
-- One checks port conflicts and stale processes (`lsof`, `pkill`)
-- One reads `docs/debug.md` and matches error messages against known issues
-- One examines the test code and Lua source for logic errors
-- One checks HyperBEAM configuration and `.env.hyperbeam`
-
-Have teammates challenge each other's findings. The theory that survives debate is most likely the root cause.
-
-### `device` — Cross-Layer Device Development
-
-Create an agent team for building a HyperBEAM device:
-- **Erlang teammate**: writes the device module in `HyperBEAM/src/`, reads `docs/hyperbeam-dev.md`
-- **JS teammate**: writes the integration test in `test/`, reads `docs/wao-sdk.md`
-- **Compile teammate**: handles `cd HyperBEAM && rebar3 compile`, fixes compilation errors
-
-**File ownership:**
-- Erlang: `HyperBEAM/src/dev_*.erl` only
-- JS: `test/*.device.test.js` only
-- Compile: `HyperBEAM/` (compile and fix only)
-
-### `review` — Parallel Code Review
-
-Create an agent team with 3 reviewers:
-- **Security reviewer**: checks for wallet exposure, injection, auth bypass
-- **Correctness reviewer**: validates AOS script logic, state management, edge cases
-- **Test coverage reviewer**: ensures all AOS scripts have tests, edge cases covered
-
-### `module` — Custom Module Development
-
-Create an agent team for building custom WASM64 or Lua modules:
-- **Module teammate**: writes the custom module source (custom-wasm/src/lib.rs or custom-lua/{name}.lua)
-- **Test teammate**: writes HyperBEAM integration tests in `test/`, reads SDK docs for cacheBinary/cacheScript patterns
-- **Build teammate**: handles compilation (cargo build for WASM, HyperBEAM startup for Lua)
-
-**File ownership:**
-- Module: `custom-wasm/` or `custom-lua/` only
-- Test: `test/*-module.test.js` only
-- Build: runs compilation and HB processes, doesn't edit source
-
-## Guidelines
-
-- Assign 5-6 tasks per teammate to keep everyone productive
-- Each teammate should own separate files — never have two teammates edit the same file
-- Workers report back test results, not just "done"
-- Use delegate mode (Shift+Tab) if you want the lead to only coordinate, not code
-- Teammates load CLAUDE.md and docs/ automatically — give task-specific context in spawn prompts
-- Use Shift+Up/Down to cycle between teammates and message them directly
-- Always clean up the team when done (tell the lead to clean up)

package/esm/workspace/.claude/skills/test/SKILL.md

@@ -1,56 +0,0 @@
----
-name: test
-description: "Run in-memory AOS tests (legacynet units). Fast unit testing — no server needed. Use when testing AOS scripts or after code changes. Not for HyperBEAM integration tests — use /test-hb instead."
-argument-hint: "[test-file]"
-disable-model-invocation: true
-allowed-tools: Bash, Read, Grep
----
-
-Run in-memory AOS tests. For HyperBEAM integration tests, use `/test-hb` instead.
-
-## Examples
-
-```
-/test                          # run all tests
-/test test/token.test.js       # run specific file
-```
-
-## Steps
-
-1. Kill any stale `beam.smp` or HyperBEAM processes that may be lingering on ports 10000-10010:
-
-```bash
-lsof -ti :10000-10010 | xargs -r kill -9 2>/dev/null || true
-pkill -f beam.smp 2>/dev/null || true
-```
-
-2. Run the tests:
-
-```bash
-# Specific file (if argument provided)
-yarn test $ARGUMENTS
-
-# All tests (if no argument)
-yarn test
-```
-
-3. Report results:
-   - Show pass/fail count
-   - If failures, show the failing test names and error messages
-   - Suggest fixes if the errors are obvious
-
-## Troubleshooting
-
-### Tests hang indefinitely
-- Likely cause: `Send().receive()` in Lua source — does NOT work on genesis-wasm
-- Fix: Replace with fire-and-forget `Send()` + separate handler
-- Also check for infinite loops in Lua state
-
-### "Cannot find module wao/test"
-- Run `yarn install` to ensure dependencies are installed
-- Check `package.json` has `"wao"` in dependencies
-
-### WASM memory error
-- Node 24+ enables wasm-memory64 by default — DO NOT pass `--experimental-wasm-memory64` (it's rejected with "bad option")
-- Node 22: set `NODE_OPTIONS=--experimental-wasm-memory64` before running
-- Node.js 22+ required