genesys-demo

Drive the Genesys Archy CLI — installing it, authenticating, and running create/publish/export/validate/checkin against an org. Use whenever a task involves publishing or exporting an Architect flow, deleting or unlocking flows, running archy refresh, or interpreting an Archy exit code (100, 107, 108, 123, 124) or a flow-delete failure (HTTP 405, 409, 410). Use it too when Archy behaves in a way the documentation does not explain — a fresh install that "cannot find the path", YAML that fails at line 2 for no visible reason, a published flow whose caller cannot see its outputs, or a client secret appearing in logs. Reach for it before improvising any Archy command, because most of its failure modes are silent or misreported.

Analyze a Genesys Cloud AVA version definition for authoring quality issues and build an in-memory AnalysisReport with change suggestions. Used by the ava-critique subagent. Applies quick-guide checks first, then deepens findings via cookbook references. Use when reviewing an AVA role, tools, knowledge, configuration, or guardrails for best-practice violations.

Build and publish a Genesys Cloud AVA from a design artifact. Use after the design skill has produced a design-artifact.json. Handles both new AVA creation and updating an existing AVA version. Validates the definition before sending to the Sage API.

Review a Genesys Cloud AVA design or published version for quality issues. Use when asked to critique, audit, or review an AVA for Polaris 28 compliance, payload correctness, test coverage, or deployment readiness. Can review a design artifact or a live published spec.

Design a Genesys Cloud AVA configuration. Use when collecting or editing AVA name, role, instructions, guardrails, tools, events, context variables, and test cases. Produces a design artifact consumed by the build skill. Works in both new and update mode. Also handles requirement gathering from uploaded documents and intent extraction.

Dispatch to the correct step of the full Genesys Cloud AVA lifecycle. Use when an author wants to create a new AVA, update an existing one, or run the complete design → build → test → evaluate → critique flow. Always starts here — detects org context, lists existing AVAs, and routes to the right skill.

Evaluate a published Genesys Cloud AVA by running its locally-stored, turn-based scenarios as multi-turn conversations and reporting a success-rate scorecard. Use after the test skill has authored scenarios and a test set. Projects cost first (dry run) for confirmation, then delegates each scenario to the ava-scenario-runner sub-agent (or runs sequentially in fallback), driving the actor loop via the cicero_* tools, applying Layer 1 deterministic trajectory validation and Layer 2 rubric assertion judging, persisting per-attempt results via native file-write, and scoring the whole run in one generate_scorecard call after every scenario-runner finishes.

Authors, validates, and uploads customer-facing Genesys Cloud Knowledge Fabric FileUpload content for AVA. Use when creating demo/POC knowledge, transforming documents into AI-ready cards, researching public information, or ensuring a FileUpload Knowledge Source and Knowledge Setting through the harness.

Author turn-based evaluation scenarios for a Genesys Cloud AVA and store them locally. Use after an AVA is published to define persona-driven scenarios (goal, start context, an ordered turns array, a reference trajectory for deterministic tool-call checking, and a dimension-tagged rubric) and assemble them into a test set for the evaluate skill. Scenarios and test sets are persisted on disk under `.ava-lifecycle/<slug>/` using native file I/O.

Use this skill whenever the user wants to create, read, edit, or manipulate Word documents (.docx files) or Word templates (.dotx files). Triggers include: any mention of 'Word doc', 'word document', '.docx', '.dotx', or requests to produce professional documents with formatting like tables of contents, headings, page numbers, or letterheads. Also use when extracting or reorganizing content from .docx or .dotx files, inserting or replacing images in documents, performing find-and-replace in Word files, working with tracked changes or comments, or converting content into a polished Word document. If the user asks for a 'report', 'memo', 'letter', 'template', or similar deliverable as a Word or .docx file, use this skill. Do NOT use for PDFs, spreadsheets, Google Docs, or general coding tasks unrelated to document generation.

Use the user's own Genesys brand asset library at ${CLAUDE_PLUGIN_ROOT}\assets for every icon, logo, character, motif and photograph in a Genesys deck, slide, diagram or branded document. Read this before placing any visual element. Never substitute emoji, bundled icon JSON, or third-party icon libraries.

How Genesys product content is presented in this plugin's decks: the whiteboard teaching style rather than a feature deck. Use this for any Genesys enablement, partner day, SC or AE session, product overview, channel explainer or capability walkthrough, and for any slide that has to explain what a product actually contains. It carries the pop-out anatomy shape, the one-slide-per-channel rule, the discovery-question ending, the density rules, the vocabulary, the corrections that must appear on the slide rather than in the notes, and the reveal.js geometry limits that this deck family keeps hitting. Read it before building or editing any Genesys teaching slide, including when the request sounds like a small addition, because the shape is the teaching and a slide built in a different shape breaks the room's expectation of how to read it.

Author, generate, validate, import and publish Genesys Cloud agent scripts — the .script files that drive the Script panel in the agent workspace. Use this whenever a task involves a Genesys agent script: building one from scratch, generating one programmatically, editing or repairing an existing .script export, wiring a script to data actions so it shows live customer data, adding pages or variables, or importing and publishing a script into an org. Use it too when a script misbehaves — it is missing from Architect's Set Screen Pop list, its data actions return nothing at the agent's desk, its variables read empty, or an import "succeeds" but the pages are gone. Reach for it even when the request sounds small ("add a button to our script", "why is my script not showing in the flow?"), because the .script format is undocumented and almost every part of it fails silently rather than erroring.

Build, test, reuse and edit Genesys Cloud data actions against a REST backend or the org's own API: the integration and its credential, the contract and output typing, the translation map, arithmetic that must happen inside the action and never in the model, the ten-step test, draft-and-publish editing, the org limits (500 per org, 100 per integration, drafts count) and the reuse check before anything is created. Use it for every data action a use case needs, and whenever an action returns empty strings, fails at step 10, or a total is wrong.

The running order for building a Genesys deck end to end, and the gate that decides whether it is finished. Start here for any Genesys presentation, pitch, QBR, customer briefing, readout, one-pager or single slide, rather than going straight to layout: this skill sequences the others (genesys-docs for facts, genesys-assets for visuals, genesys-board-decks for the teaching shape, genesys-html-slides for brand and build, genesys-interactive-slides for diagrams and animation) and adds the build-verify-fix loop none of them owns. Use it too whenever a Genesys deck is being reviewed, corrected or handed over, and whenever somebody asks whether a deck is ready to send.

Build a working Genesys Cloud demo end to end - take a demo request, pick or author the templates, stand up the data behind it, create the data actions, publish the flow chain and verify it before the meeting. Use whenever someone asks for a demo, a POC, a proof point or a "can we show them X" for Genesys Cloud, and whenever an existing demo needs a new customer, a new industry or a new use case. Use it too when a demo that published cleanly does not work, when deciding what a demo needs beyond flows, and when clearing up after one. Reach for it before building any single layer, because a demo built flows-first publishes perfectly and shows nothing.

Find, cite, and mirror official Genesys Cloud CX documentation from help.genesys.cloud (the Resource Center) and developer.genesys.cloud. Use this whenever a question touches Genesys Cloud — Architect flows, ACD and queue routing, bots and Copilot, WEM and workforce management, telephony, BYOC, data actions, permissions and roles, quality management, analytics views, licensing and token billing, release notes or deprecations — and whenever someone asks to look something up in the Genesys docs, cite a Genesys help article, check whether a Genesys feature exists or has changed, or build/refresh a local copy of the Resource Center. Use it even for questions that sound answerable from memory, because Genesys ships biweekly and renames features often, and use it before any web search on a Genesys topic so the search is aimed at the right domains.

Author and templatise Genesys Architect flows of any type - inbound and outbound call, chat, email, short message, in-queue, secure call, survey, voicemail, workflow, workitem, common module, bot and digital bot. Use whenever a task builds, edits, parameterises or publishes flow YAML, adds a template to the demo library, or turns a working flow into a reusable template with a per-customer profile. Use it too when a flow fails to publish or fails at runtime with an unresolved reference, when deciding whether to copy an existing flow or author a new one, and when parameterising queues, prompts, data actions, agents or TTS voices out of a flow. Reach for it even when the request sounds small, such as making one flow reusable or adding a collections template, because the parameterisation and publish-ordering rules fail silently rather than loudly.

Build presentation decks as self-contained HTML files in official Genesys branding — correct palette, Roboto type scale, real logo assets, the Bold G and EO Threads motifs, and reveal.js animation bundled offline so the file works with no internet. Also enforces the Genesys messaging framework: the loyalty-vs-efficiency narrative, approved proof points, and the words the brand forbids. Use this skill whenever the user asks for a deck, slides, a presentation, a pitch, a QBR, a customer briefing, an executive summary or a readout AND the context is Genesys — even if they don't say "HTML", don't mention branding, and even if they seem to be asking for PowerPoint. Use it too for editing or restyling an existing Genesys deck, for building a single branded slide, and for any question about Genesys brand colours, fonts, logos, layouts or messaging rules. Do NOT use for non-Genesys decks or for generic HTML pages that are not presentations.

Build the hard slides inside a Genesys HTML deck: hand-drawn SVG architecture diagrams that assemble beat by beat, live calculators and sliders the room can drag, journey strips, animated flows, exploding donut rings, and multi-fragment choreography, then verify them by measuring the rendered page in a headless browser instead of trusting how the source reads. Use this skill whenever a Genesys deck needs a diagram, an architecture or platform slide, an "X in the middle with Y on the left" picture, animation, a build-up, an interactive or numeric model, or a before/after, even if the user just says "add a slide showing how it fits together" and never says SVG, diagram or animation. Use it too for debugging a Genesys deck whose labels render at the wrong size, whose arrowheads or icons vanish, whose images sit offset or clipped, or that throws SecurityError in a preview pane. Pairs with genesys-html-slides, which owns brand, messaging and the build script.

Create or reuse the Genesys Cloud objects a use case needs around the virtual agent and its data actions: queues, wrap-up codes, knowledge bases and articles, canned responses, agent checklists, agent scripts, Web Messenger configurations and deployments, Predictive Engagement segments and action maps, and Agent Copilot (intents and the assistant). Carries the request bodies and fallback ladders proven against real orgs by the Arena builder, the use-existing-or-create rule, preflight for name clashes and org limits, and the cleanup ledger. Use it for every object in the checklist except data actions (genesys-data-actions), demo data (nocodb-demo-backend), flows (genesys-flows) and the AVA (ava-*), and whenever a create call returns 400 on an undocumented enum or HTTP 200 while creating nothing.

Build a Genesys Cloud outbound messaging campaign for a demo: a contact list with the persona's number, the contact, and a WhatsApp (or SMS) messaging campaign that sends an approved template from the org's messaging number, created switched off and started by the SC on demo day. Use it whenever a story opens with a proactive notification (a failed delivery, a flight change, an appointment reminder, a payment due), whenever an SC asks for "a campaign", "a contact list" or "send the template to the persona", and whenever a campaign shows an error message or sends nothing on the second run.

Make a demo website visible to Genesys Cloud Predictive Engagement and act on what it sees: the one tag that tracks pages and loads the messenger, segments that match the address the browser really reports, an action map that offers help at the hesitation point rather than on arrival, a "log in as" button that names the visitor, a reset that genuinely starts a new visitor, and the way an interaction ends up on a directory contact. Use it whenever an SC says "Live Now shows unknown", "the offer never appears", "the offer follows the visitor to every page", "how do I reset the session", or wants the agent to receive who the web visitor is. Everything here was measured on a live deployment; the reference carries the endpoints and the scripts that measured it.

Sign a person in to Genesys Cloud from an app you are building — OAuth clients, grants, redirect URIs, scopes, and what a website can and cannot do. Use when adding "log in with Genesys" to a tool, when a login returns "The OAuth client ID or redirect URI is invalid", when deciding between implicit and PKCE, when a service-account token cannot answer /users/me, when choosing scopes, or when someone asks why a browser extension needs no OAuth client and a website does. Covers the Genesys GDemo extension's token-borrowing trick and why it cannot be copied. Read-only knowledge plus tools/oauth-client.mjs, which finds or creates the client so nobody types a GUID.

Build Genesys Cloud speech and text analytics for a demo: the topics that spot what the story is about, the program that holds them, the publish job that makes them live, and the queue and flow mappings that scope them to this use case. Also turns transcription on where it is off, which is the reason most voice demos show nothing. Use it whenever an SC asks for "topics", "a program", "speech analytics", "text analytics", "topic spotting" or "sentiment", whenever a use case wants a guardrail measured rather than claimed, and whenever a demo shows no topics, no transcript or no sentiment on a call.

Build Genesys Cloud work automation for a demo: the workitem schema that holds the custom fields, the workbin that holds the work, the worktype that ties them to a queue with its statuses, and the workitems themselves created from a conversation. Use it whenever a story continues after the call ends, whenever an SC asks for "a workitem", "a worktype", "a workbin", "a case", "back office" or "task management", whenever an assistant should hand work to a team rather than a person, and whenever a worktype cannot be deleted or a create returns 409.

Build and maintain NocoDB databases that back contact-centre and CRM demos — creating tables, seeding realistic personas, and shaping the schema so an external system (especially Genesys Cloud data actions) can actually read and write it. Use this whenever a task involves NocoDB: standing up demo tables, designing a schema a REST integration will query, seeding or correcting demo data, or debugging why a lookup returns zero rows, a write silently fails, or a boolean column is wrong. Use it for the shared demo database the plugin's setup page connects (the host is stored on the SC's computer, never in this text): it carries the conventions and the surveying you must do before adding tables to a database other people share. Reach for it even when the request sounds like plain data modelling ("create tables for a banking demo", "add some test customers"), because a schema that reads fine in the NocoDB UI can be unusable from an integration, and the failures are silent.

The Genesys Demo: build a Genesys Cloud use case end to end in the SC's own org. Use this for anything that starts a use case, a POC, a demo or a proof point ("build me a use case", "I need a demo where...", "set up an assistant for..."), for connecting to an org for the first time, for resuming a use case from a previous session, and for any question about what the builder does or what it will produce. It owns the running order: connect and read the org, six questions, the read-back, the checklist of objects, the plan, build one step at a time with a check before every change, test and rehearse, deliverables, share. Every other Genesys skill in this plugin is called from here, including the AVA design, build and test skills: a brief that reads like an AVA design request ("checkpoint", "design the agent", a tool list, a persona and a hard boundary) still starts here, never in ava-dispatch or ava-design, and never offline.