| name | solo-customize-workspace |
| description | Customize Solo workspaces, windows, sidebar, navigation, command palette, keymaps, appearance, external tools, notifications, account display, and updates. Use when organizing or personalizing Solo's app-level workspace experience. Do not use for repository or solo.yml changes, process lifecycle, or agent work. |
Customize Solo Workspace
Configure Solo's application shell around existing projects and processes. Preserve running work, local preferences, and neighboring skill boundaries.
Read relevant references
- Read references/workspaces-navigation.md for workspaces, windows, sidebar, favorites, resource indicators, navigation, palettes, and keymaps.
- Read references/settings-appearance.md for Settings tabs, appearance, terminal display, and external editor/terminal/browser choices.
- Read references/notifications-account-updates.md for notifications, licensing, updates, quitting, and destructive cautions.
- Read only references needed for request. Use cited official URLs when behavior or labels may have changed.
Keep scope bounded
- Handle workspace grouping, app windows, app navigation, UI preferences, notification policy, and account/update surfaces.
- Route project creation, directory changes, onboarding, command detection, and
solo.yml work to $solo-set-up-projects.
- Route command creation, trust, start/stop/restart, auto-start, auto-restart, output, ports, and process cleanup to
$solo-run-processes or $solo-observe-services as appropriate.
- Route agent-tool setup, health, launch, resume, and session interaction to
$solo-work-with-agents.
- Route multi-agent plans, todos, scratchpads, locks, timers, and worker coordination to
$solo-orchestrate-agents.
- Change only app/workspace preferences when request mixes domains; state which remaining work belongs elsewhere.
Follow customization workflow
- Identify desired outcome: organization, navigation speed, visual density, appearance, notification signal, or account/update check.
- Inspect current state before changing it. Use Solo MCP read/list/help tools when available; otherwise guide user to exact live Settings or UI surface.
- Check live MCP catalog, current Solo version, Settings labels, and relevant official docs before relying on version-sensitive behavior. Treat changelog as newer than stale screenshots or marketing copy.
- Choose smallest reversible change. Prefer local settings over project mutations.
- Preview consequences before moving projects, deleting workspaces, changing notification levels, deactivating a license, installing an update, or relaunching.
- Apply only authorized changes. Never infer permission for billing, license deactivation, update installation, quit/relaunch, workspace deletion, or process termination.
- Verify resulting workspace/window assignment, visible sidebar order, active shortcut, effective theme/font, or notification level. Report any UI-only step user must complete.
Customize workspaces and windows
- Create workspace only when grouping improves current project set; one workspace is valid and hides rail.
- Move projects between workspaces without changing repository config. Confirm destination and current window ownership.
- Reorder workspaces when numbered bindings or rail order matter.
- Move workspace to new window for multi-monitor layout; remember one workspace can be open in only one window.
- Before deleting populated workspace, require destination for contained projects. Never imply disk files are deleted.
- Use workspace launcher for cross-workspace search and drag moves when direct MCP support is absent.
Tune sidebar and navigation
- Reorder Todos, Agents, Terminals, Commands, and Scratchpads per project or change default subgroup order when request is global.
- Use collapse state, per-section empty visibility, filter input, favorites, and resource thresholds to reduce noise before hiding useful signals.
- Preserve unread and running visibility. Running lesser-used commands remain visible by design.
- Remap configurable hotkeys only after checking collisions and fixed shortcuts.
- Distinguish command center, context actions, quick jump, focus jump, prompt templates, and new-item palettes; do not overload one shortcut with another mode's job.
Tune settings and appearance
- Keep interface and terminal typography separate.
- Use Light, Dark, or System unless live Settings proves a named theme picker exists.
- Preserve readable focus indicators and terminal font coverage.
- Test custom editor/terminal entries before making them defaults. Do not promise system fallback when no tool is configured.
- Keep device-local preferences out of
solo.yml.
Tune notifications safely
- Separate native background alerts, in-app toasts, unread indicators, and bell sounds.
- Resolve project/process levels using most restrictive effective setting: All, Important, or None.
- Prefer Important for noisy processes when crashes matter but BEL/OSC events do not.
- Verify OS permission, Focus/Do Not Disturb, same-process suppression, and rate limiting before calling notification delivery broken.
Handle account and updates cautiously
- Read license/account state before suggesting activation or upgrade.
- Never expose, copy into output, or persist license keys or bearer tokens.
- Do not deactivate or move a license without explicit request; deactivation can stop processes when usage exceeds free limits.
- Do not install an update or relaunch while processes run without explicit confirmation. Explain that commands, agents, and terminals stop on quit/relaunch.
- Prefer checking update availability and release notes over applying update when request is informational.
Verify completion
- Re-read affected Solo state or revisit exact Settings control.
- Confirm no project config, command lifecycle, or agent session changed unless separately authorized through neighboring skill.
- Cite current docs/changelog for any version-sensitive caveat.
- Summarize changed preference, scope, and any deferred UI action in a few lines.
