opencode

Explore vague or ambitious ideas into a right-sized requirements-only unified plan. Use when the user wants to brainstorm, think through scope, decide what to build, or needs collaborative product framing before planning. Also use when the user must scope work in territory they say they do not know ("I know nothing about X but need to...") or asks for a blindspot pass — mapping the decision surface before questions begin. Not for executing already-specified work — direct implementation, debugging, or code review where no product scope is left to decide. Not for a decisive verdict on whether to adopt or switch to a specific external technology, library, or platform — brainstorming scopes what to build, not whether to commit to an outside option.

Generate comprehensive hierarchical codemaps for UNFAMILIAR repositories. Expensive operation - only use when explicitly asked for codebase documentation or initial repository mapping

High-cost orchestrator workflow for large, high-risk, multi-phase coding efforts with meaningful dependencies and review gates. Do not activate for routine multi-file changes.

Configure and improve oh-my-opencode-slim for the current user. Use when users want to tune agents, models, prompts, custom agents, skills, MCPs, presets, or plugin behavior. Also use when recurring workflow friction suggests a safe config or prompt improvement.

Review recent work, find repeated workflow patterns, and suggest reusable skills, agents, commands, config changes, or playbooks. Use when the user asks to learn from past sessions, improve recurring workflows, or identify what should be turned into reusable agent instructions.

Manage Git worktrees as OMO safe isolated coding lanes for complex, risky, or parallel work.

Use when building a new UI or reshaping an existing one and the brief needs a distinctive visual identity rather than a templated default. Triggers on "design a landing page", "make this less generic", "choose palette/typography", or "visual direction". Grounds choices in the subject world, names one signature element, takes one justified aesthetic risk, and avoids common AI-default looks.

Use when polishing UI details: components, animations, micro-interactions, typography, shadows, hit areas, or anything that makes an interface feel "off". Triggers on "make it feel better", "UI polish", "stagger", "scale on press", "border radius", "tabular nums", "font smoothing", or "optical alignment". Enforces concrete design-engineering principles and a Before/After review table.

Use when working in a shadcn-svelte project: adding, updating, fixing, composing, or styling components. Triggers on "shadcn-svelte init", "add a component", "registry", "components.json", or imports from $lib/components/ui/*. Treats components.json as the source of truth for aliases, theme, iconLibrary, and registry. Multi-part components use import * as Dialog; single-component barrels use import { Button }.

Use when creating, editing, reviewing, or analysing Svelte 5 components (.svelte) or Svelte modules (.svelte.ts/.svelte.js). Triggers on "Svelte 5", "rune", "$state", "$derived", "$effect", "svelte component", or uncertainty about Svelte syntax. Uses the @sveltejs/mcp CLI for docs lookup and svelte-autofixer before finalising.

Use when auditing, profiling, debugging, or optimising page load performance, Lighthouse scores, Core Web Vitals, or site speed. Triggers on "slow page", "poor LCP/INP/CLS", "performance audit", "why is the page heavy", Lighthouse, or render-blocking/network/cache concerns. Uses Chrome DevTools MCP trace + network + a11y snapshot, then codebase analysis; checks web.dev/Chrome docs for current thresholds.