← ClaudeAtlas

walnut-console-opslisted

Operating the Walnut web UI (localhost:3456) via Playwright MCP tools — understanding the UI layout, chatting with main agent, interacting with sessions, monitoring status changes. Use when asked to test, verify, or interact with the Walnut web console as a human user would.
EvanZhang008/open-walnut · ★ 6 · AI & Automation · score 79
Install: claude install-skill EvanZhang008/open-walnut
# Walnut Web Console — How It Works This skill explains the Walnut web UI so you can operate it confidently via Playwright MCP tools, acting as a human user. ## Core Mental Models for SPA Console Testing These principles are universal — they apply to any single-page app, not just Walnut. ### 1. Stay on one page — panels, not pages SPAs show everything through panels that open/close on the same page. Don't navigate away to find something. The session panel opens inline when you click a session link — you don't need the `/sessions` page. ### 2. Disambiguate inputs by placeholder Multiple input boxes coexist on screen. They look identical in the DOM. **Placeholder text** is the reliable discriminator. Check it before typing. ### 3. Same state, multiple renderings — verify all One piece of state (e.g., "session mode") appears in 3+ places, each with different update paths (REST vs WebSocket vs React state). Check all of them. Bugs often show as one updating while another stays stale. ### 4. Act → Wait → Verify Every action triggers async work. Pattern: **Act** → **Wait** (5-20s) → **Screenshot** (visual truth) → **Snapshot** (clickable refs). Skip the wait = see stale state. ### 5. Screenshot is ground truth Screenshot shows what the user sees. DOM snapshot shows logical tree. When they disagree, trust the screenshot. ### 6. Refs are ephemeral Playwright refs (`ref=e1234`) are tied to a specific DOM state. Any async change invalidates them. Always re-snapshot before inte