liveavatar-feedback
Collect and submit developer feedback to the LiveAvatar team. Use when: (1) A LiveAvatar integration is done, working, finished, or complete, (2) The user says "it works", "we're done", "that's it", "ship it", (3) The user is frustrated, stuck, or giving up — "this is broken", "this doesn't work", "
By heygen-com · 711 installs
npx skills add heygen-com/liveavatar-agent-skills --skill liveavatar-feedback
Source repository · Upstream listing
LiveAvatar Feedback Collection
This skill collects integration feedback and sends it to the LiveAvatar team. It fires in three scenarios:
1. Post implementation — the user just finished an integration (Embed, FULL, or LITE)
2. Frustration detected — repeated errors, explicit complaints, or visible friction
3. Explicit request — the user asks to give feedback or report an issue
When to Trigger
Activate this skill when ANY of these are true:
The user says they're done or the integration is working
The user expresses frustration ("this is broken", "why doesn't this work", "I'm stuck")
The user explicitly asks to give feedback, report a bug, or share a suggestion
You've seen 3+ failed attempts at the same step during integration
The user says they're giving up or abandoning the integration
Do NOT trigger unprompted in the middle of active implementation. Wait for a natural pause or completion point.
Step 1: Gather Context from the Conversation
Before prompting the user, review the conversation history and silently compile:
Use case — what the user is building (e.g., "customer support avatar for a SaaS dashboard"). This comes from the discovery phase, the user's stated goal, or their codebase.
Blockers — anything that caused friction during the integration. Look for: errors hit, steps that required retries, confusing API behavior, silent failures, missing docs, or anything the user explicitly complained about.
Compact both into short, factual summaries. These are telemetry the agent drafts — the user will review them before anything is sent.
Step 2: Ask the User for Permission and Additional Feedback
You must get explicit permission before sending anything. Present what you've gathered and ask the user to approve, edit, or decline.
Adapt tone to context — celebratory after success, empathetic if frustrated.
After successful implementation:
When frustration is detected:
On explicit feedback request:
Wait for the user to explicitly approve (e.g., "yes", "send it", "looks good", "go ahead"). If the user says no, declines, or ignores the prompt — do not send the request. Drop it.
Step 3: Map to Fields
Field Source What goes here
use case Agent compacted from conversation Short summary of what the user is building (e.g., "Customer support avatar for SaaS dashboard")
blockers Agent compacted from conversation What caused friction — errors, retries, confusion, silent failures (e.g., "Silent avatar due to missing context id — no error thrown, took 30 min to diagnose")
additional feedback User's own words, verbatim Freeform input the user wrote when prompted — feature requests, suggestions, general thoughts. Use the user's exact words. Do not rephrase or summarize.
All three fields are optional. Omit or pass null for anything that doesn't apply:
No frustration or issues during integration? Omit blockers .
User didn't write any additional feedback? Omit additional feedback .
Couldn't determine use case from context? Omit use case .
Step 4: Send the Feedback (only after explicit consent)
Only execute this step if the user explicitly approved in Step 2. If the user declined, edited, or didn't respond — stop here.
This call runs on the BACKEND using X API KEY .
Constructing the request
use case and blockers : use the compacted summaries you showed the user in Step 2 (with any edits they requested).
additional feedback : paste the user's freeform text verbatim . Do not rephrase.
Omit or pass null for any field that doesn't apply.
If the user edited your summaries in Step 2, use the edited versions.
If the user's API key is available in the environment (e.g., HEYGEN API KEY or LIVEAVATAR API KEY ), use it. Otherwise, tell the user you need their API key to submit the feedback.
Example payloads
Agent compacted telemetry only (user had no additional feedback):
Full payload with user's own words:
Step 5: Confirm Submission
After sending, confirm to the user:
Keep it brief. If the request fails (e.g., invalid API key), tell the user and offer to show them the curl command so they can send it manually.
Gotchas
1. Consent is mandatory. Never send the request without the user's explicit "yes." If in doubt, ask again. If the user ignores the prompt, do not send.
2. Don't fabricate additional feedback . That field is the user's own words only. use case and blockers are agent compacted, but additional feedback must be verbatim user input or omitted entirely. Never generate, summarize, or pre fill this field yourself — if the user didn't write anything, omit it from the payload.
3. Show before you send. Always show the user the exact content you plan to send and let them edit or remove anything before you fire the request.
4. Don't interrupt flow. If the user is mid implementation, don't jump to feedback collection. Wait for a natural break.
5. API key required. This endpoint uses X API KEY . If you don't have access to it, show the user the curl command instead of failing silently.
6. All fields are optional. A valid request can have just one field populated and the rest omitted or null.