VoicenterTeam

Designs the structural skeleton of a Voicenter Bot via interview. Use this skill when the user wants to create, design, scope, or modify a Voicenter voice/chat bot — phrases like "design a bot", "create an agent spec", "build a Voicenter bot", "patch this bot", "add an intent", "change the bot's persona", "modify the flow graph", or any reference to the Agent Spec Designer / Skill 1 in the Voicenter bot generation pipeline. Produces an Agent Spec markdown file (sections 1-4, 4.5, section 5 stubs, section 6 initial, section 7 init). Two named entry modes — greenfield (no spec attached) and patch (spec attached). Does NOT author per-intent language content (validationPrompt, post-execution intentInstructions) — that's Skill 2 (Intent Detail Author). Does NOT emit wire-format JSON — that's Skill 3 (JSON Assembler).

Assembles a fully-detailed Voicenter Agent Spec into Bot JSON wire format — the final mechanical step in the three-skill pipeline. Use this skill when an Agent Spec exists with all section 5 entries marked `[detailed]` and the user wants the deployable JSON. Trigger phrases include "run Skill 3", "assemble the JSON", "emit the bot JSON", "publish the bot", "build the wire-format", "Skill 3 (JSON Assembler)", or any direct continuation from Skill 2's completion handoff. Produces a single `bot-<name>-<date>.json` file plus a banner identifying every fail-loud sentinel and any drift between spec section 6 and what Skill 3 regenerated. Refuses to assemble if any intent is still `[structural]` or `[detailed-revisit]`, or if the spec deviates from the strict template (Doc 2 §3.7). Runs the §15.4 cross-reference pass — 23 checks (8 §15.4 + 3 Compass + 3 botIntents-role + 1 duplicate-global-intent + 8 field-placement doctrine), checks 1–7, 11–13, 15, and 16–21 blocking. Does NOT author any text content (Skills 1 and

Authors the per-intent language content of a Voicenter Agent Spec — slot descriptions, validationPrompt, post-execution intentInstructions, and RT-specific Configuration text. Use this skill when an Agent Spec exists with section 5 entries marked `[structural]` or `[detailed-revisit]`, and the user wants to fill them in. Trigger phrases include "run Skill 2", "detail the intents", "fill in the per-intent fields", "Skill 2 (Intent Detail Author)", or any direct continuation from Skill 1's handoff hint. Walks intents in user-confirmed batches with a checkpoint after each batch. Reactivable — invoke as many times as needed; spec state is the resume point. Does NOT modify the structural skeleton (sections 1, 2, 3, 4, 4.5.1/.2/.4) — that's Skill 1 (Agent Spec Designer). Does NOT emit wire-format JSON — that's Skill 3 (JSON Assembler).

Pull call detail records (CDR) from Voicenter using the Call Log API

Receive and handle CDR push notifications from Voicenter after every call ends

Initiate or terminate outgoing calls using the Voicenter Click2Call API

Implement a Pop-Up Screen endpoint that Voicenter calls during incoming calls to display caller CRM data to agents

CRM integration scoping & onboarding playbook. Use when scoping a NEW CRM integration, running a discovery/feasibility/spec meeting, or choosing between API vs Chrome extension vs local BAT, Push vs Pull, and CRM-owned vs Voicenter-owned screen pop. Covers: CRM type detection (on-premise vs web), entity/field mapping, Click2Call station-code setup, screen pop architecture (who owns it), trigger-stage rules (ring/answer/hangup), call history method (CDR Push vs Call Log Pull), and full decision checklist. Trigger on: new CRM, CRM onboarding, integration spec, feasibility, station code, screen pop ownership, on-premise vs web CRM, Push vs Pull.

Interpret Gossipper output artifacts (summary JSON, trace CSVs, call records JSONL, OTLP events) and produce a structured findings report. Use whenever the user wants to classify failures from a Gossipper run, evaluate latency or media quality verdicts, decide whether a run passed health thresholds, propose threshold values for the next run, convert RTCP jitter from RTP timestamp units to milliseconds, surface Call-IDs and time windows for HOMER/qryn correlation, interpret exit code 2, or read a "Run report" handed over from gossipper-run.

Write or modify Gossipper XML scenarios for SIP load testing. Use whenever the user wants to create, edit, port, or convert SIP scenarios for the sipcapture/gossipper load generator — UAC/UAS flows, REGISTER with digest auth, 3PCC master/slave coordination, scenarios with RTP media, or porting SIPp XML to Gossipper. Also use for questions about Gossipper XML syntax, supported actions/keywords, or SIPp compatibility status of a feature.

Invoke the sipcapture/gossipper SIP load generator. Use whenever the user wants to run a Gossipper scenario, set CLI flags / transport mode / rate / volume / output flags, wire correlation identifiers for HEP or OTEL, author a 3PCC peer file, convert a PCAP to scenarios via `pcap2scenario`, smoke-test a freshly authored scenario, build a run-profile JSON for systemd or long-running deployment, set health thresholds, or interpret a Gossipper exit code. Also use for questions about the `gossipper -h` surface or `gossipper server` management mode.

Reviews OpenSIPs configurations for security issues — authentication and credential storage, injection (SQL/shell/header), MI exposure, TLS posture, DoS surfaces, relay and routing risks, identity spoofing, STIR/SHAKEN, media plane, dispatcher/load-balancer, tracing/logging hygiene, and configuration hygiene. Use whenever the user asks for a security review, audit, or hardening check on an OpenSIPs config, mentions risks like SIP scanning, spoofed REGISTER, INVITE flood, toll fraud, MI exposure, RTP relay misuse, or cites a CVE in an OpenSIPs context. Do NOT use for general SIP security advice unrelated to OpenSIPs configuration.

Authors, edits, reviews, and answers questions about OpenSIPs SIP server configuration files (opensips.cfg, route blocks, modules, parameters, pseudo-variables). Use whenever the user mentions OpenSIPs, opensips.cfg, route{}/branch_route/failure_route, $var/$avp/$pv pseudo-variables, asks to write/edit SIP routing logic for OpenSIPs, names a specific OpenSIPs module (tm, dialog, dispatcher, registrar, drouting, presence, sl, uac, db_mysql, mid_registrar, etc.), or asks what functions/parameters a module exports. Do NOT use for sibling SIP Express Router (SER)-lineage projects — those use different identifiers despite shared lineage.