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:
- Announce the step in plain words (e.g. "Let's connect your agent") — phase numbers are internal navigation, never user-facing.
- Read the phase file (
phaseN-*.mdin this skill directory). Do not rely on memory of its contents. - Complete every task in the file and satisfy its gate condition.
- Confirm the step in plain words and move on without waiting for the user (no "Phase N complete").
Ask questions ONLY to collect missing inputs or resolve genuine ambiguity (provider choice, credentials, phone number, self-hosted confirmation). Don't pause to re-confirm an action the flow already implies — the user invoked onboarding, which is a request to create the agent, enable metrics, generate evaluators, and start the first verification run. (Your client's own tool-permission prompts still apply as normal.) 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.
Onboarding is self-contained. Do NOT open the sibling cekura-create-agent skill (or any other skill) during onboarding — everything needed (credential matrix, description quality bar) is inlined in this skill's phase files. cekura-create-agent's phase sequence covers post-onboarding work (SDK integration, mock tools, knowledge base) and running it mid-onboarding hijacks the flow into those steps; it is a Phase-6 handoff only.
The Phases
| Phase | File | What happens | Path |
|---|---|---|---|
| 0 | phase0-path.md | Pick testing vs observability; ONE aiagents_list call to detect existing work |
shared |
| 2 | phase2-agent.md | Create/connect the agent — provider-first, minimal, validated | shared |
| 3T | phase3-testing-metrics.md | Verify default metrics (auto-enabled at project creation) | testing |
| 4T | phase4-testing-evaluators.md | Generate first evaluators (generation-first) | testing |
| 5T | phase5-testing-first-run.md | First test run + verification gate | testing |
| 6T | phase6-testing-next.md | What's next (SDK, mock tools, custom metrics) | testing |
| 3O | phase3-observability-ingest.md | Ingest call logs + verification gate | observability |
| 4O | phase4-observability-metrics.md | Configure starter metrics | observability |
| 5O | phase5-observability-evaluate.md | Run metric evaluation | observability |
| 6O | phase6-observability-review.md | Review results, what's next | observability |
(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.