Established

Modes and personas

Named modes that swap instructions, tools and tone for a context of use rather than a model.

MTicket #4821Duplicate charge · Dana Ortiz

Reply mode config v4

Write to the customer in our support voice. Never promise money back; billing decides that.

Tools it can use

Data it can read

Public help center · this customer's tickets

Hands back

A draft for you to edit and send

Help me with this ticket.

Milky Reply mode

Try it: Switch modes on the same request. Each mode loads different tools and data, so the work changes, not just the tone.

In the wild

How one product ships this pattern. Click a screenshot to enlarge it.

Kagi Assistant picker with tabs Assistants, Custom and Models; the Custom tab lists custom assistants Code, Study and News, with an Add New link and an Entire Web scope toggle beside it. — Kagi Assistant
Custom assistants such as Code, Study and News are picked from the same menu as models. Each bundles its own instructions, model and search scope.
Source: Kagi docs ↗

When to use

One product serving distinct jobs — research, coding, drafting, tutoring.

Seen in

ChatGPT custom GPTs, Gemini Gems, Claude styles, Perplexity focus modes, Cursor modes.

For engineers

Define modes as versioned config: system prompt, tool allowlist, retrieval scope, defaults.

Build prompt

A neutral, component-only prompt for a coding agent. Edit the stack block or anything else to fit your project, then copy it.

# Build the "Modes and personas" pattern: `ModeSwitcher`

## Stack (edit this block to match your project)
- React 18+ with TypeScript: one function component, typed props, no `any`.
- Tailwind CSS, using your design system's tokens if you have them.
- Presentational only: data comes in through props, decisions go out through callbacks. No fetching or global state inside.
- If your codebase already has conventions (naming, shared components, tokens), follow them over this spec.

## What the pattern is for
Named modes that swap instructions, tools and tone for a context of use rather than a model.

Use it when: One product serving distinct jobs — research, coding, drafting, tutoring.

## What to build
A switcher for named modes, where each mode is a different setup of instructions, tools, data access and output, not just a tone. It shows exactly what changes when a person switches, so the choice is meaningful. It renders as tabs or a menu above a composer or work area.

### Props
- `modes`: Array<{ id: string; name: string; purpose: string; version: string; instructions: string; tools: Array<{ id: string; label: string }>; dataScope: string; output: string }>, from versioned config.
- `selectedId`: string and `onSelect(id: string)`, the controlled current mode.
- `showDetails?`: boolean, expands the configuration summary under the switcher (default true on first use).
- `status`: "ready" | "switching" | "error".
- `onViewConfig?(id: string)`: opens the full mode definition elsewhere.
- `labels?`: Partial<Record<"tools" | "data" | "output" | "instructions", string>>.

### States it must render
- Ready: the current mode marked, with its purpose and a summary: instructions in one line, the tools it can use as chips, the data it can read, and what it hands back.
- Compare on hover or focus: the summary for the other mode, with what differs from the current mode marked (tools added or removed, wider or narrower data).
- Switching: the new mode is marked and the summary updates; the composer stays usable.
- Collapsed: only mode names and the current version label.
- Error: the mode could not load; stay on the previous mode and say so.

### Interactions
- Selecting a mode calls `onSelect`; the summary updates to that mode's config.
- A details toggle shows or hides the summary.
- Arrow keys move between modes; selection follows focus only if switching is cheap, otherwise Enter confirms.

### Edge cases
- Two modes with identical tools, data and output: render a visible note "Same capabilities, different instructions" so the difference is honest.
- Switching mid-conversation: say whether earlier messages stay and that new replies use the new mode; mark each reply with the mode that produced it.
- A mode with no tools: show "No tools" explicitly rather than an empty list.
- Config version changes: show the new version label next to the mode name.

## Must avoid
Modes that only change tone while the actual capability is identical, so the choice is theatre.

## Engineering constraint
Define modes as versioned config: system prompt, tool allowlist, retrieval scope, defaults.

## Accessibility
- Modes are a `tablist` (or radio group) with the summary as the associated panel; the panel's heading names the mode.
- Tool added or removed markers are text ("adds", "removes"), not colour only.

## House rules
- Real `<button>`/`<input>` elements, full keyboard use, visible focus; announce status changes with `aria-live="polite"`; respect `prefers-reduced-motion`.
- All user-facing text comes from props (or a `labels` prop) so it can be translated.
- One consistent accent marks anything the AI made or is doing; amber means "needs a person", red means risky, green means done. Never rely on colour alone.
- Fits a 360 px wide container without horizontal scrolling.

## Acceptance checks
- [ ] Every state above can be rendered by passing props, with no internal fake data.
- [ ] Every interaction and edge case above behaves as described.
- [ ] Nothing in "Must avoid" can happen with this component.

## Deliver
1. The component file with its exported prop types.
2. A short usage example that renders each state.

Download this prompt as Markdown, or every prompt as JSON for an agent.

Critique checklist for tuners

0 of 4 checked

These questions apply to every pattern in this family. Ticks are saved in this browser.

Is there a way to adjust without rewriting the prompt?
Are controls labelled in outcomes, not model parameters?
Does changing a control preserve the parts the user liked?
Is the previous result still reachable after a tune?