Segment

Plan, create, update, and bind Sunboard segments through the CLI.

/sunboard.segment plans, creates, updates, or binds a segment. Segments decide who sees an experience — trial users, enterprise admins, a lifecycle stage, accounts above a size threshold. They live in the hosted control plane, not in YAML, so this skill never edits your spec files.

When to use it

  • Targeting an experience to a specific cohort.
  • Binding a deployed version live (create a segment, then attach it).
  • Pausing, resuming, or detaching an existing deployment.

What happens

  1. Inspects hosted state (sunboard state) — which segments, experiences, and bindings already exist.
  2. Agrees on the audience in product terms — role, plan, lifecycle stage, activation status, account size, and who to exclude.
  3. Reuses before creating — one canonical segment per cohort, not parallel duplicates.
  4. Proposes rules in plain English, then JSON — property rules ({ property, equals }) and event rules ({ event, notCompleted }), grouped by all/any. See Segmentation for the full rule model.
  5. Dry-runs, then confirms — every mutation is previewed and explicitly approved before it applies.
  6. Optionally binds the segment to an experience version with routing attach, and prints the Sunboard URL.

Mutations are deliberate, and hosted

Targeting is hosted state — editing YAML won't fix it. Every change is shown as a --dry-run diff and only applied after you confirm in words. Deleting a segment requires detaching its deployments first.

On this page