The Assistant
The in-dashboard AI assistant — what you can ask, what it renders, and how it turns a measurement plan into live resources plus a ticket for the code it can't write.
Describe the outcome. It wires up the flags, experiments, and metrics.
A chat assistant built into the dashboard. It reads your project to answer questions, and proposes every change as a card you confirm — gates, configs, kill switches, experiments, metrics, and alert rules. Nothing happens until you approve it.
How it works
Open the assistant from the orb in the dashboard and ask in plain language. It works in two modes, and it picks the right one for you:
Read — answer from your project→
To answer a question it calls read-only tools and shows them as a live thinking trace ("✓ Reading your project", "✓ Checking experiment status"). It never changes anything to answer.
Write — propose a change→
To change something it emits the matching action as an editable confirmation card. The change runs only when you press Confirm — so it's safe (and expected) for it to propose a mutation directly instead of asking permission first.
The assistant is scoped to the project you're viewing and authenticates with your session. It reads live state and proposes changes only in that project.
What it produces
Every reply is built from a small set of interactive elements rather than a wall of text.
Answers (markdown)
Short, formatted prose — bold, inline code, and lists — with the result first. Reasoning is
kept out of the answer; if the model thinks, it's tucked behind a dim "Thought for a moment" toggle.
Thinking trace
While it works, each read action shows as a trace line that resolves with a check mark — so you can see exactly what it looked at (your gates, an experiment's enrolment, a page on your site).
Choice chooser
When it needs a decision to continue, it asks with clickable options instead of a numbered list. Pick one and the conversation continues with your answer. Some questions also offer a free-text "Something else…" field.
Confirmation cards
Any change is an editable card. Tweak the fields, then Confirm to apply or Cancel to dismiss. The assistant can propose:
Feature gates→
Create, update, enable/disable, or delete a gate — rollout %, targeting rules, environments.
Dynamic configs→
Create, update, or delete a typed config value with targeting.
Kill switches→
Create/update/delete a kill switch, or flip a named per-key override on one environment.
Experiments→
Draft an A/B experiment (groups, allocation, targeting gate, success metric), update it, or start/stop it.
Universes→
Create, update, or delete a universe (the holdout boundary experiments share).
Metrics & alert rules→
Create an event-backed metric, and a metric-threshold alert rule that watches it.
Nothing is created, changed, or deleted until you confirm the card. The assistant never claims an action succeeded — you apply it yourself. Deleting resources is also available in the dashboard UI.
Plan cards
For multi-step work — the common case being "measure this" (instrument an event → create a metric → maybe add an alert) — it proposes an approvable plan instead of a markdown checklist. Each step is one of two kinds:
- Instant — a resource it can create immediately (a metric, an experiment, an alert rule).
- Ship — code instrumentation it can't write from the dashboard (emitting an event from your app). These are captured for your team to implement.
Measurement plans & the measure_plan ticket
A measurement plan usually needs both kinds of work: create the metric and emit the event the metric counts. The assistant in the dashboard has no access to your repository, so it does the half it can and hands off the half it can't.
You approve the plan
Press Approve plan on the plan card.Instant resources are created on the spot
Metrics, experiments, and alert rules in the plan are created immediately and linked to the plan.
Code work becomes a ticket
The event instrumentation (and anything that couldn't be created yet, e.g. a metric whose event
isn't emitted in your code) is filed as a single measure_plan ticket in Feedback →
Measures, with the linked resources and the exact events to emit.
Your ship bot implements it
The ops:work loop (Claude Code running in your repo) picks up the ticket,
instruments the events, creates any pending resources, opens a PR, and flips the ticket to
ready_for_qa. Once the events flow, the linked metrics start collecting.
The split is by environment, not a setting. Running the same plan from Claude Code in your
project (via the Shipeasy skills/MCP) implements everything directly — instrumentation included
— and files no ticket. The measure_plan ticket exists only because the website assistant
can't touch your code.
Credits
Assistant usage is metered in credits (each seat includes a monthly allowance; top up from the panel when you run low). If you run out mid-turn, the assistant shows an add-credits prompt and pauses until you refill.
Where to next
What the gate / config / experiment cards produce, and how rollouts and analysis work.
Read →MeasureMetricsHow event-backed metrics and the metric DSL work — what the assistant builds for a plan.
Read →ShipFeedback & ops:workThe unified ticket queue (bugs, requests, errors, alerts, and measure_plan) your ship bot
burns down.