Spec

/sunboard.spec authors or revises the YAML for one onboarding experience — there's one experience per cohort. It's usually run by Onboarding (or Analyze), which decide the activation goal, the cohorts, and whether a survey is needed; this skill turns that plan into a valid spec.

When to use it

• As a step of /sunboard.onboarding — the usual path.
• Directly, when you want to revise a single experience's steps or copy without re-planning the whole flow.

What happens

1. Studies your product — README, routes, entry points, and existing experiences.
2. Reads hosted state with sunboard state so it reuses experience keys and segments instead of inventing parallel ones. To revise a live experience, it reads the current spec with sunboard pull <key>.
3. Takes the activation goal and cohort as inputs — value, not configuration (e.g. workflow.created, not profile.completed). It doesn't run a fresh strategy interview; that's Onboarding's job.
4. Drafts the experience, then composes the spec in context (Sunboard is fileless — nothing is written to your repo): usually an ordered checklist (3–5 steps) with optional tours, personalized copy, and a completion screen. The checklist is optional, so an experience can be tours alone, for in-app guidance that starts from the UI instead of a checklist.
5. Validates it with sunboard validate (piping the spec on stdin) and flags any assumptions to confirm.

What you get

A validated spec ready to deploy, plus a short customer-success plan: the activation goal, the suggested segment and exclusions, the data-sunboard-id selectors and track() calls that still need wiring, and the analytics to watch.

Related