Skill

visualizing-options

Use when a design discussion needs visual options shown in a browser: mockups, layout comparisons, wireframes, or architecture diagrams that the user can click to choose between. Spawns a local server and renders content fragments.

npx claudepluginhub pgoell/pgoell-claude-tools --plugin workbench

Tool Access

This skill uses the workspace's default tool permissions.

Preview

Browser-based visual companion for showing mockups, layouts, wireframes, and diagrams during a design discussion. The user opens a local URL; you write HTML content fragments to a session directory; clicks are recorded back as JSON events.

Supporting Assets

scripts/frame-template.htmlscripts/helper.jsscripts/server.cjsscripts/start-server.shscripts/stop-server.shvisual-companion.md

SKILL.md

Similar Skills

using-superpowers

183.2k

Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.

3 files

superpowers

Stats

Parent Repo Stars0

Parent Repo Forks0

Last CommitMay 6, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

Visualizing Design Options

When to Use

Decide per question, not per session. The test: would the user understand this better by seeing it than reading it?

Use the browser when the content itself is visual:

UI mockups: wireframes, layouts, navigation structures, component designs.
Architecture diagrams: system components, data flow, relationship maps.
Side-by-side visual comparisons: two layouts, two color schemes.
Design polish: look and feel, spacing, visual hierarchy.

Use the terminal otherwise: requirements, scope, conceptual A/B/C choices, tradeoff lists, technical decisions.

A question about a UI topic is not automatically a visual question. "What kind of wizard do you want?" is conceptual. "Which of these wizard layouts feels right?" is visual.

Quick Start

scripts/start-server.sh --project-dir /path/to/project

The script returns startup JSON with url, screen_dir, and state_dir. Save those values for the loop.

If you launched the server in the background and did not capture stdout, read $STATE_DIR/server-info to recover them.

Pass --project-dir so mockups persist in .workbench/brainstorm/. Without it, files go to /tmp and get cleaned up on stop. Add .workbench/ to .gitignore if not already.

The Loop

Check the server is alive ($STATE_DIR/server-info exists, $STATE_DIR/server-stopped does not). Restart with start-server.sh if it has shut down.
Write a new HTML file to screen_dir using the Write tool. Use semantic filenames (platform.html, layout.html); never reuse names.
Tell the user what is on screen and remind them of the URL. End your turn.
On your next turn, read $STATE_DIR/events for click events. Merge with the user's terminal text.
Iterate (write a new file with a version suffix) or advance.
When returning to the terminal for non-visual questions, push a waiting screen (<p class="subtitle">Continuing in terminal...</p>) so the browser does not show stale content.

Cleanup

scripts/stop-server.sh $SESSION_DIR

Project-dir sessions persist in .workbench/brainstorm/ for reference. Sessions writing to /tmp get deleted on stop.

Reference

For the deep guide (CSS classes, content fragments vs full documents, platform-specific server start, design tips, file naming, browser events format), see visual-companion.md in this skill's directory.