CtrlK
BlogDocsLog inGet started
Tessl Logo

cekura-fixing-prod-issues

Debugs a failing production call, reproduces the bug with Cekura evaluators, implements a fix, verifies it, runs regression tests, then raises a PR with evidence. Use when the user wants to fix a production call bug, investigate a failing prod call, reproduce and fix a production issue, run regression tests before a PR, or says things like "fix this prod call issue", "debug and fix call ID", "test my fix against prod scenarios", "reproduce this production bug", or "regression test before raising PR".

75

Quality

92%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Advisory

Suggest reviewing before use

SKILL.md
Quality
Evals
Security

Fixing Production Call Issues

Full workflow — debug first, reproduce before fixing, test thoroughly, then PR.

Phase 1      Phase 2         Phase 3     Phase 4        Phase 5        Phase 6
Debug   →   Reproduce   →   Fix    →   Verify    →   Regression  →   PR
Understand   Confirm bug     Write the   Same eval      Happy paths    All result
root cause   on Cekura       code fix    must PASS      + edge cases   URLs in PR
             BEFORE fix      + commit    now            pass too

The 6 Phases

PhaseFileWhat happens
1phase1-debug.mdFetch prod call + logs, identify root cause, confirm with user
2phase2-reproduce.mdBuild evaluator, attach metrics, run — eval must fail before any fix
3phase3-fix.mdWrite the code fix, commit locally
4phase4-verify.mdRe-run same evaluator — eval must pass now
5phase5-regression.mdTest all affected happy paths and edge cases
6phase6-pr.mdRaise PR with all Cekura result URLs

Strictness Rules — Read Before Starting

These rules are non-negotiable. Do not proceed past a gate without satisfying it.

Rule 0 — Use the same connection medium as the production call. No exceptions.

Every reproduction, verification, and regression test MUST be a full end-to-end simulation on Cekura using the same transport the agent is configured for. Retrieve the agent record (GET /test_framework/v1/ai-agents/{id}/) to confirm its transport. Most likely telephony, but follow what the agent is actually configured to use.

❌ Text mode is never a valid substitute. ❌ Do not switch transports between phases.

The bug lives in the real call path; only a simulation over the same medium can confirm it.

Rule 1 — Phases are sequential. No skipping.

Each phase has a gate. A gate is not passed by assumption — it is passed by evidence. The sequence exists because:

  • You cannot write a good fix without understanding the root cause (Phase 1 gate)
  • You cannot trust a fix without first proving the bug exists in a controlled way (Phase 2 gate)
  • You cannot call regression tests meaningful without a passing fix verification (Phase 4 gate)

Rule 2 — Phase 2 is the hardest gate. Treat it as such.

Reproducing the bug is the most critical step. Do not move to Phase 3 until the eval definitively fails on Cekura with metric scores showing the failure. If there is any doubt about whether the bug is truly reproduced, stop and ask the user. Do not guess.

Rule 3 — When in doubt, ask.

If you are unsure which metrics to use, whether the root cause is correct, whether the edge conditions are right, or whether a result is ambiguous — stop and ask the user. A wrong assumption here wastes the entire workflow.

Rule 4 — Never push code until Phase 5 is complete.

The commit happens in Phase 3. The push happens only after all regression tests pass in Phase 5.

Repository
cekura-ai/cekura-skills
Last updated
Created

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.