菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Review recent activity and generate a standup update. Use when the user asks for a standup, "what did I do yesterday", or a daily summary.
Install, configure, verify, update, and remove Walnut plugins from git repos through the Plugin Store REST API. Use when the user pastes a plugin share snippet ({"walnut_plugin_source": ...}) or a git repo URL and wants the plugin installed, or says "install plugin", "add plugin source", "update/remove a plugin", or asks why a plugin is not active.
Distill a workflow, doc, or conversation into a reusable skill. Use when the user says "learn this", "save this as a skill", or wants a procedure captured for reuse.
Register a repository — delegate a Claude Code session to explore the codebase and create a structured profile. Use when the user says "register repo", "add this repo", or wants a repository profile created.
Triage and prioritize pending tasks. Use when the user asks to triage, review priorities, clean up stale tasks, or decide what to work on next.
Summarize the week's progress across all projects. Use when the user asks for a weekly review, week summary, or "what happened this week".
| name | walnut-console-ops |
| description | 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. |
| requires | {"bins":[]} |
This skill explains the Walnut web UI so you can operate it confidently via Playwright MCP tools, acting as a human user.
These principles are universal — they apply to any single-page app, not just Walnut.
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.
Multiple input boxes coexist on screen. They look identical in the DOM. Placeholder text is the reliable discriminator. Check it before typing.
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.
Every action triggers async work. Pattern: Act → Wait (5-20s) → Screenshot (visual truth) → Snapshot (clickable refs). Skip the wait = see stale state.
Screenshot shows what the user sees. DOM snapshot shows logical tree. When they disagree, trust the screenshot.
Playwright refs (ref=e1234) are tied to a specific DOM state. Any async change invalidates them. Always re-snapshot before interacting.
Frontend changes (vite build) take effect on page refresh. Backend changes (npm run build) need server restart. Common mistake: build the fix, test, see no change — server is still running old code.
When the UI doesn't update: (1) Did backend emit the event? → (2) Did WebSocket forward it? → (3) Did frontend listen for it? → (4) Did component re-render? The bug is always at one stage.
These patterns apply to any app where you chat with an AI agent that spawns background sessions.
There's a main agent (orchestrator) and individual sessions (workers). They have separate inputs. Typing in the wrong one sends your message to the wrong place. The main agent can create sessions, but once a session exists, you interact with it directly through its own input.
Sessions go through states: created → running → stopped. They also have a work status (in_progress, awaiting_human, agent_complete) and a mode (bypass, plan, etc.). These update in real-time via WebSocket. Status displays in multiple UI locations, each updated by different code paths.
When the agent creates a session and shows a link, click it to open a session panel inline on the same page. Don't navigate to a separate sessions page. The session panel has its own chat history, input box, and status header — all distinct from the main chat.
/)┌────────┬─────────────────┬─────────────────┬──────────────────┐
│Sidebar │ Main Chat │ SessionPanel │ TodoPanel │
│ │ │ │ ┌─────────────┐ │
│ Home │ Chat history │ Session header │ │ Task list │ │
│ Tasks │ (main agent) │ (status, mode) │ │ (grouped by │ │
│ Sess. │ │ │ │ cat → proj)│ │
│ Search │ │ Session chat │ ├─────────────┤ │
│ Memory │ │ (You ↔ Claude) │ │ TodoDetail │ │
│ ... │ │ │ │ Sessions │ │
│ │ ┌─────────────┐ │ │ │ Summary │ │
│ │ │ Chat input │ │ Session input │ │ Triage │ │
│ │ └─────────────┘ │ │ └─────────────┘ │
│ │ Task context │ │ Quick add │
└────────┴─────────────────┴─────────────────┴──────────────────┘
SessionPanel only appears when a session is open. Without it, Main Chat takes more space.
Where you talk to the main agent. It can create tasks, start sessions, query data, run tools. When it starts a session, it responds with a clickable session link:
✅ Session started: Session Title
Input placeholder: "Type a message... (/ for commands)" or "Ask about '<task name>'..."
Task list grouped by Category → Project. Each task row shows phase icon, title, SessionPill (e.g., plan · Awaiting Human / Stopped), priority, star. Clicking a task opens TodoDetailPanel below.
Shows detail for the selected task:
↗View Triage History (N) →Clicking a session in this list also opens SessionPanel.
Session chat with the Claude Code CLI process. Contains:
📋 Task Name ↗"Send a message to this session... (/ for commands)"The session input sends messages directly to the Claude Code CLI process — not through the main agent.
/)×) → returns to layout without it| Input | Placeholder | Purpose |
|---|---|---|
| Main chat | "Type a message..." or "Ask about '...'" | Talk to main agent |
| Session chat | "Send a message to this session..." | Talk directly to Claude Code CLI |
| Task search | "Search tasks... ⌘K" | Filter tasks in TodoPanel |
| Quick add | "Quick add task..." | Create task directly (no agent) |
Talk to the main agent: "Create task 'My Task' in Projects/Walnut, start a bypass session with prompt 'Just say HI'"
Session modes: bypass (execute immediately), plan (investigate → write plan → ExitPlanMode)
"Send a message to this session...")After an action, check three places:
plan / session) + status| Route | What it is |
|---|---|
/ | Home — main chat + SessionPanel + TodoPanel (most common) |
/tasks | Full task board |
/tasks/:id | Task detail page (standalone, different from TodoDetailPanel) |
/sessions | Session tree browser (rarely needed from home) |
/search | Full-text search |
Most of the time, / gives you everything you need.
Prefer:
browser_take_screenshot — see what a real user sees, catch visual bugsbrowser_snapshot — accessibility tree with clickable refsbrowser_click — click buttons, links, tabs like a user wouldbrowser_type + browser_press_key — type into inputs and press EnterUse sparingly:
browser_evaluate / browser_run_code — useful for waits, but don't bypass the UIPrinciple: if a human would click a button, you click that button.
browser_snapshot — most useful tool, gives refs for clickingbrowser_take_screenshot — visual truth when DOM looks fine but something's wrongbrowser_run_code — await page.waitForTimeout(5000) for delaysbrowser_network_requests — check API calls and WebSocket framesbrowser_console_messages — check for JS errors/tmp/walnut/walnut-YYYY-MM-DD.log) — when UI doesn't update, check if backend sent the eventsession:status-changed carries mode/work_status/process_status; task:updated carries task data; session:started/session:ended for lifecycle