Cekura Platform Onboarding

Walk a new user from account to their first verified result — a completed test call with a visible transcript (testing) or a scored production call (observability).

The One Principle

Keep onboarding minimal, but it may only end at a verified working loop — never at "records created".

• Minimal: one high-leverage connection step per provider; everything else (SDK, mock tools, KB, dynamic variables, custom metrics) is deferred to after the first result.
• Verified: onboarding is NOT done when the agent/scenario rows exist. It is done when one test call completed and its transcript is visible (testing), or one call log is ingested and scored (observability). A misconfigured SIP endpoint or unsupported phone number must surface during onboarding, not days later.

Two Paths

Both paths share Phases 0 and 2 (path choice, agent connection) and diverge after that. The first objective is always connecting the agent — there is no separate account/project phase: working tools prove auth, and a missing project is handled inline (projects_list / projects_create) on the way into Phase 2.

• Testing (default) — generate evaluators, run them against the agent in simulation, review results.
• Observability — ingest production call logs, attach metrics, evaluate, review.

Execution Model — Read This First

This skill executes one phase at a time, in order. For each phase:

1. Announce: "Starting Phase N — [name]".
2. Read the phase file (phaseN-*.md in this skill directory). Do not rely on memory of its contents.
3. Complete every task in the file and satisfy its gate condition.
4. Announce: "Phase N complete." and move to the next phase without waiting for the user.

Ask questions ONLY to collect missing inputs or resolve genuine ambiguity (provider choice, credentials, phone number, self-hosted confirmation). Never ask permission to continue, never confirm an action the flow already implies — the user invoked onboarding, so creating the agent, enabling metrics, generating evaluators, and starting the first verification run are all pre-authorized. No "ready to continue?", no "shall I create it?", no "want me to proceed?" — just do the step and narrate it. The one exception: when a gate is blocked (e.g. the testing-path description gate) present the blocker and the options.

Several phases delegate to files in the sibling cekura-create-agent skill (../cekura-create-agent/…). When a phase file tells you to read one of those, follow only the referenced guidance — ignore that file's own phase gates and "continue to Phase N+1" instructions; return to this skill's flow.

The Phases

(There is no Phase 1 — the old account/project phase is retired; client/OAuth setup lives in references/client-setup.md as a fallback and phase numbering is kept stable.)

Performing Platform Actions

Prefer the platform tools over describing API calls or dashboard steps — actually call the tool. If a call fails, fix the cause or ask for the missing input, then retry; never claim a step is done until the call succeeds.

Never invent IDs

Every agent ID, scenario ID, call log ID, metric ID, and run ID comes from a real tool response. If you don't have an ID, call the relevant list/retrieve tool. Provider-side identifiers (VAPI assistant IDs, API keys, webhook URLs) come from the user — never guess.

Documentation

• Public docs: https://docs.cekura.ai
• LLM-friendly docs: https://docs.cekura.ai/llms.txt
• Integrations: https://docs.cekura.ai/documentation/integrations/
• references/api-quickstart.md — essential endpoints used during onboarding.