Developer Tool CLI & IDE Plugin UI

What this prompt does

This prompt generates a complete, opinionated UI specification for developer tools — covering the command palette, workspace layout, keyboard shortcut system, output panel, settings interface, and status bar as discrete, implementation-ready sections. It works because it encodes the actual conventions developers have internalized from tools like VS Code, Zed, and Warp: monospace-first typography, dark charcoal backgrounds, sub-100ms feedback, and syntax-highlighting color palettes applied to UI accents — not just code.

The anti-pattern list is the real differentiator. By explicitly instructing the model to avoid rounded cards, slow animations, and light-mode-only designs, the prompt prevents the default "pretty SaaS" aesthetic that makes developer tools feel wrong the moment you open them. The [framework] variable drives the final section, which generates an implementation of the command palette and workspace layout in your chosen stack — so you get runnable component code for those two critical sections, not just a prose spec.

The [integration_context] variable is where you describe where the tool lives: a VS Code extension sidebar, a standalone Electron window, a JetBrains plugin panel, or a browser DevTools extension. This context changes every interaction assumption the model makes — a sidebar panel gets a condensed single-column layout with collapsed panels; a standalone window gets full split-pane workspace treatment.

When to use it

• You are building a CLI companion app (log viewer, deployment dashboard, database explorer) and need a coherent visual system before writing a line of frontend code.
• Your team is designing a VS Code extension or JetBrains plugin and wants to align on interaction patterns before splitting into parallel work.
• You are pitching a developer tool to stakeholders and need a realistic, high-fidelity mockup specification rather than generic Figma frames.
• You are evaluating whether a tool's UX matches developer expectations before a public beta.
• You inherited a developer tool with inconsistent UI and need a reference spec to refactor toward.

Example output

For [tool_type]: "Kubernetes log aggregator", [developer_persona]: "Platform engineer running 20+ services", [core_workflow]: "Filtering and tailing logs across namespaces in real time", [integration_context]: "Standalone Electron window", [framework]: "React + xterm.js":

Command Palette (Cmd+K):
  > namespace:production filter:error last:5m
  > pod:api-gateway tail --follow
  Recent: [namespace:staging filter:warn] [pod:worker-3 grep "OOM"]
  Categories: Namespaces | Pods | Filters | Views | Settings

Workspace: split-pane — namespace tree (left 240px) | live log stream (main) | parsed JSON inspector (right 320px, toggleable)

Keyboard shortcuts:
  Ctrl+Shift+F  — focus filter input
  Ctrl+\         — toggle JSON inspector
  G then G       — scroll to bottom of log stream (chord)
  Ctrl+K         — clear current stream

Output panel: xterm.js instance, ANSI color passthrough, auto-scroll locked unless user scrolls up (banner: "▲ Paused — press G to resume")

Settings: JSON editor view default, GUI toggle in top-right; schema-validated, errors inline

Status bar: connected to cluster prod-us-east | 3 streams active | latency 12ms | branch: main

(Truncated — the full prompt output also includes the React + xterm.js implementation of the command palette and workspace layout.)

Pro tips

• Set [developer_persona] with precision: "backend engineer who lives in the terminal" generates a denser, more keyboard-centric output than a vague "developer." The persona shapes every section — shortcut density, information hierarchy, even the default panel layout.
• The [workspace_layout] variable is the highest-leverage input. Describe the layout structurally — "three-column: file tree | diff view | AI suggestions panel" — not conceptually like "clean and organized." The model derives keyboard navigation and panel resize behavior from the structural description.
• The [integration_context] variable is not cosmetic. "VS Code extension sidebar" versus "standalone Electron window" produces fundamentally different workspace layouts and keyboard shortcut systems — a sidebar gets constrained width with collapsed sections, a standalone window gets full multi-pane treatment. Fill this in before anything else.
• The [framework] slot accepts both frontend stacks (React, Svelte, Tauri) and terminal UI libraries (Ink, Bubble Tea, Textual). The command palette and workspace implementation adapts meaningfully to each — Ink gives you a terminal-rendered palette with keyboard event handlers; React gives you a DOM-based cmdk-style component.
• If your tool has a light-mode requirement (enterprise compliance, accessibility), explicitly override the dark-mode default in your prompt. The anti-pattern instruction will otherwise suppress light-mode output entirely, which is intentional for most use cases but will silently omit light theme variants if you need them.