mcpField
C
cekura-onboarding

cekura-onboarding

github.com/cekura-aiTesting & quality885 installsUpdated 2d ago
Repository

About cekura-onboarding

A Cekura onboarding skill that helps new users connect an agent and reach a verified testing or observability result. It keeps initial setup focused on the first completed test call with a visible transcript, or an ingested and scored production call.

Key features

  1. 01Testing and observability paths
  2. 02Provider-first agent connection
  3. 03First-result verification gates
  4. 04Evaluator generation and metric setup
  5. 05Call-log ingestion and review

Use cases

  1. 01Run and verify an agent simulation
  2. 02Ingest and score production call logs
  3. 03Configure metrics and generate evaluators

MCP support

Prefers Cekura platform tools to perform onboarding actions, including listing or creating projects, connecting agents, and running verification steps.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/cekura-ai/cekura-skills --skill cekura-onboarding

After installing, type/cekura-onboardingin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

phase0-path.md
phase2-agent.md
phase3-observability-ingest.md
phase3-testing-metrics.md
phase4-observability-metrics.md
phase4-testing-evaluators.md
phase5-observability-evaluate.md
phase5-testing-first-run.md
phase6-observability-review.md
phase6-testing-next.md
agents/
openai.yaml
references/
api-quickstart.md
client-setup.md

Details

From the project README

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 the step in plain words (e.g. "Let's connect your agent") — phase numbers are internal navigation, never user-facing.
  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. 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

PhaseFileWhat happensPath
0phase0-path.mdPick testing vs observability; ONE aiagents_list call to detect existing workshared
2phase2-agent.mdCreate/connect the agent — provider-first, minimal, validatedshared
3Tphase3-testing-metrics.mdVerify default metrics (auto-enabled at project creation)testing
4Tphase4-testing-evaluators.mdGenerate first evaluators (generation-first)testing
5Tphase5-testing-first-run.mdFirst test run + verification gatetesting
6Tphase6-testing-next.mdWhat's next (SDK, mock tools, custom metrics)testing
3Ophase3-observability-ingest.mdIngest call logs + verification gateobservability
4Ophase4-observability-metrics.mdConfigure starter metricsobservability
5Ophase5-observability-evaluate.mdRun metric evaluationobservability
6Ophase6-observability-review.mdReview results, what's nextobservability

(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

Comments

Markdown supported