菜单
When the user asks what is going on with the site they are building, drive the in-app browser Tools endpoints to start the dev server, read console + server + network logs, inspect/eval the page, and report -- all inside Symphonee, no Chrome needed.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
The disciplined way to make and land a code change in a Symphonee-managed repo -- branch, implement, verify, show the diff as its own step, then commit. Use for any implement/fix/refactor task that ends in a commit.
How to safely edit and validate Symphonee's dashboard renderer. The served js/app.js and mind-ui.js are GENERATED build outputs -- edit the source under dashboard/public/app/src/shell/ or mind-ui/src/, rebuild, then validate.
Turn a correction, a gotcha, or a procedure you just did well into a durable SKILL.md so every future session of every CLI inherits it. This is how the system improves its own behaviour, not just its knowledge.
Engineered, not rushed -- profile and understand the system before changing it, find root cause not symptoms, then implement deliberately. Use for any non-trivial fix or feature where the right design is not obvious.
When a task matches an installed plugin or a structured connector, use its REST routes -- never re-solve it by hand or shell out to a third-party CLI. Ask the user before invoking a plugin.
For substantial or autonomous multi-step work, commit to a reviewable contract -- intent, a plan with acceptance criteria, then execute proving each unit with evidence -- instead of improvising. Use for overnight/large tasks or anything that must be auditable.
| name | Diagnose the running app |
| description | When the user asks what is going on with the site they are building, drive the in-app browser Tools endpoints to start the dev server, read console + server + network logs, inspect/eval the page, and report -- all inside Symphonee, no Chrome needed. |
| when | the user asks 'what is going on?', 'why isn't X working?', 'is the server up?', 'check the logs', or reports a bug on the local site being developed |
| tags | browser, devtools, debugging, diagnostics, tools-drawer |
The in-app browser Tools drawer exposes everything as REST, so you can diagnose the user's site end-to-end without leaving Symphonee or spending an LLM browser-agent loop. Do this proactively when the user is vague ('what's going on?').
GET /api/git/status?repo=<activeRepo> is irrelevant here; instead check the project's dev server:GET /api/browser/server-log?lines=80 -> returns the active repo's dev-server terminal output (auto-detected), with isDevServer + devUrl.termId:null / no dev output, the server is probably not running. Start it: read GET /api/project/scripts?repo=<activeRepo> for the dev script, create a terminal and run it (POST /api/orchestrator/spawn or the terminal hub), then poll server-log until devUrl appears.POST /api/browser/launch then POST /api/browser/navigate {url:<devUrl>} (or the route the user mentioned).GET /api/browser/console?limit=100 (includes uncaught exceptions).GET /api/browser/network?limit=100; body of a failed call: GET /api/browser/network-body?requestId=....GET /api/browser/server-log for stack traces the browser never sees.POST /api/browser/inspect {selector} or GET /api/browser/dom.POST /api/browser/eval {expression} runs JS in the page and returns the value (read state, reproduce the bug, check a global).The user sees all of this live in the Tools drawer (Console / Network / Server / Elements / AI), docked bottom/left/right. Reading is permission-free; mutating (eval, style, navigate, submit) is gated -- say what you're about to do first.