## User Feedback Analysis — 2026-02-04 (based on 2026-02-01 to 2026-02-03 community/GitHub signals) ### Data sources referenced - Discord discussions: 2026-02-01, 2026-02-02, 2026-02-03 (coders, core-devs, discussion, partners) - GitHub activity snapshot (month window starting 2026-02-01): new issues around character/prompting, billing, messaging integrations --- ## 1) Pain Point Categorization (top recurring friction areas) ### 1) **Technical Functionality** — Skill invocation reliability (high severity, frequent among builders) **What users report** - Skills frequently fail to trigger even when documentation is available. One evaluation found **skills not triggered in 56% of cases** (R0am). - Workaround patterns exist (forced step-by-step tool selection), but they make conversations feel unnatural (“a bit weird but it works”). **Who it impacts most** - Anyone building agents that must reliably call tools/skills (automation, integrations, multi-step tasks). --- ### 2) **Integration / Platform Access** — ElizaCloud API & account/billing gating (high severity, blocks onboarding) **What users report** - **API key creation fails without a credit card**, even when the account has free credits (DorianD). - x402 payments are disabled on free tier, blocking bot-style testing without a card. - Account duplication issue: using different Proton email aliases (`@proton.me` vs `@protonmail.com`) caused an agent to “disappear” from the dashboard (yojo), likely due to separate accounts. **Who it impacts most** - Developers trying to test Cloud quickly, and users managing multiple identities/providers. --- ### 3) **Documentation / UX** — Token migration process confusion and failure (high severity, highly emotional) **What users report** - Repeated migration failures and unclear edge cases (bridge not detecting tokens, “Max amount reached”, wallet balances showing zero). - One user reported **>$4,000 loss** attributed to migration difficulty (E S P E R A N Z A 🦋). - Newcomers repeatedly asked whether migration was “true or a scam,” and what happens after deadline; responses often redirect to support channels rather than resolving root confusion. **Who it impacts most** - Token holders (including non-technical users). This is reputationally risky. --- ### 4) **Technical Functionality / Security** — Malicious skills & plugin trust (high severity, emerging) **What users report** - Concern about “malicious skills on clawhub” (jin). - Proposed mitigations: scanner skills, code rewriting/adaptation phases, and LLM review (Odilitime); sandboxing suggested (jin). **Who it impacts most** - Plugin ecosystem users; any marketplace/distribution of third-party skills. --- ### 5) **UX/UI / Product Capability** — Image generation lacks visual consistency (medium-high severity for creators) **What users report** - elizacloud.ai cannot maintain consistent characters/branding across iterations; follow-up “edits” regenerate entirely new visuals (yojo). - Users either spend excessive time prompt-engineering or leave the platform for external tools (workflow break). **Who it impacts most** - Storytelling, brand asset generation, iterative design workflows. --- ### 6) **Documentation / Developer Experience** — Branch/tooling confusion & platform compatibility (medium severity, recurring) **What users report** - Core functionality and fixes live on **odi-dev branch**; community is warned not to use main (Odilitime). This indicates users can easily end up on outdated code. - Tooling constraints: Codex app “Apple Silicon only” (limits contributor/dev reach). **Who it impacts most** - New contributors and builders trying to follow “main branch = stable” expectations; non-macOS or non-Apple Silicon developers. --- ### 7) **Community / Communication** — “What is shipping?” and rollout expectations (medium severity) **What users report** - Uncertainty around OpenClaw integration timeline (“everyone gets Eliza first; custom agents weeks later”) (Borko). - Broader meta-issue: market/community doesn’t understand what’s being built; messaging/positioning gap noted internally (DannyNOR). **Who it impacts most** - New users deciding whether to invest time; partners evaluating integration timing. --- ## 2) Usage Pattern Analysis (actual vs intended usage) ### How users are actually using elizaOS 1. **Automation + external signals ingestion** - Example: Solana DIaaS delivering trading signals via API; users want agents to consume and act via plugins (Lucas Alpes). 2. **Agent-as-a-product workflows** - Expectation: agents should “relentlessly try to do stuff” with minimal setup (DorianD). Users value autonomy over configurability. 3. **Cloud-first testing** - Users want quick API keys and bot testing without payment friction; current Cloud gating conflicts with this. 4. **Creator workflows** - Branding/storytelling image iteration is a real demand; users expect edit/consistency loops, not single-shot generations. 5. **Security-sensitive plugin ecosystems** - As plugins/skills become primary extension mechanism, users assume some level of marketplace safety and execution isolation. ### Emerging / unexpected use cases - **Distributed agent challenge participation** (CICADA-71): implies demand for multi-agent coordination, adversarial robustness (prompt injection), and reproducible evaluation harnesses. ### Feature requests aligned with observed usage - Standardized **plugin consumption patterns** (API schema conventions, examples, templates). - **Reliability layer** for skill/tool invocation (prompt/tool policy scaffolding). - **LoRA / identity consistency** capability for images or an “edit mode” workflow. - Cloud onboarding improvements: **API keys without credit card**, x402-enabled top-ups for dev testing. --- ## 3) Implementation Opportunities (solutions by major pain point) ### A) Skill invocation reliability (56% failure observed) **Opportunities (prioritized by impact / difficulty)** 1) **High impact / Medium difficulty:** Add an “explicit tool-selection” policy mode in core - Productize R0am’s 3-step hook as an optional runtime setting (e.g., `tool_policy=strict`). - Provide a first-class “tool deliberation” trace UI for debugging why a skill wasn’t called. - Similar approaches: **Zapier MCP / Composio** style enforced tool gating (already referenced by users). 2) **High impact / Medium difficulty:** Improve skill metadata quality + automatic linting - Enforce structured skill descriptions (inputs/outputs/examples) and add a linter that flags ambiguous triggers. - Auto-generate few-shot examples per skill (ties to GitHub issue on character/prompt iteration #6447). 3) **Medium impact / Higher difficulty:** Add a lightweight planner/executor split - A planner step produces an explicit tool-call plan (JSON), executor follows it. - Similar pattern: ReAct/plan-and-execute agents used across LangChain-style frameworks. --- ### B) ElizaCloud API key creation requires credit card; x402 disabled on free tier; account duplication **Opportunities** 1) **High impact / Low-medium difficulty:** Introduce “Developer Mode” Cloud accounts - Allow API key issuance with rate limits and lower quotas without a card. - Gate higher limits behind payment verification. - Similar pattern: Stripe test mode; many SaaS products allow free API keys with strict quotas. 2) **High impact / Medium difficulty:** Enable x402 for free tier top-ups (or dev-only) - Permit x402 micro-topups to avoid credit-card requirement for testing. - Provide clear UI for “pay with x402” vs “add card”. 3) **High impact / Medium difficulty:** Fix identity normalization for email aliases - Canonicalize Proton variants (or treat provider aliasing explicitly) and add account-merge flow. - Add UI warnings when logging in with a new email alias that will create a separate account. - Similar pattern: GitHub/Google account linking and “merge accounts” support flows. --- ### C) Token migration confusion/errors and user losses **Opportunities** 1) **High impact / Low difficulty:** Publish a single “Migration Status & Known Issues” page - List: token age detection rules (pre-Nov 2025), common errors (“Max amount reached”, balance=0), exact deadline time, and escalation path. - Add screenshots and decision tree. - Similar pattern: Ethereum L2 bridges maintain “status + FAQ + known issues” pages. 2) **High impact / Medium difficulty:** Add automated pre-flight checks in the bridge UI - Wallet scan + token eligibility + likely error detection before the user submits a transaction. - Provide “why not detected?” explanation (contract versions, snapshots, cutoff blocks). 3) **Medium-high impact / Medium difficulty:** Post-migration receipts + audit trail - Generate a verifiable receipt page per wallet: source holdings, conversion rate, tx hashes, final balance. - Reduces perception of “lost funds” and support load. --- ### D) Malicious skills / plugin security **Opportunities** 1) **High impact / Medium difficulty:** Establish a “trusted skills” pipeline + signing - Require skill packages to be signed; display trust level (verified publisher vs unverified). - Similar pattern: VS Code Marketplace publisher verification; npm package provenance. 2) **High impact / Medium difficulty:** Sandboxed execution for third-party skills - Run skills in isolated environments (WASM, container sandbox, or microVM like Firecracker) with restricted network/fs by default. - Provide explicit permission prompts for elevated capabilities. - Similar pattern: browser extension permission model; GitHub Actions permission scoping. 3) **Medium impact / Low-medium difficulty:** Automated scanning + LLM review as a gate - Implement scanner skills + static checks (secrets, obfuscation, suspicious syscalls) before publication. - Use LLM review to summarize risk, but do not rely on it as sole enforcement. --- ### E) Image generation consistency & edit workflows **Opportunities** 1) **High impact / Medium difficulty:** Add “Character/Brand ID” feature (LoRA or embedding-based) - Let users create a persistent identity asset; subsequent generations reference it. - Similar pattern: creator workflows in image tools that support LoRA-based consistent characters. 2) **High impact / Medium difficulty:** Implement “edit mode” (inpainting/outpainting / targeted changes) - Support “remove hat, keep face” style edits rather than full regeneration. 3) **Medium impact / Low difficulty:** Provide an official “consistency workflow template” - Even before full product changes, document recommended pipeline: seed locking, reference images, style tokens, and when to use external tools. --- ### F) Branch/tooling confusion (odi-dev vs main) + Apple Silicon limitation **Opportunities** 1) **High impact / Low difficulty:** Clarify stability channels (release branches) - Create a clear stable branch/tag; communicate “main vs dev” policy. - Add CI badges and “recommended branch” banner in README and docs. 2) **Medium impact / Medium difficulty:** Nightly builds / release notes automation - Auto-publish changelogs summarizing what’s in odi-dev that isn’t in main. - Similar pattern: Homebrew “stable vs HEAD”, or VS Code Insiders vs Stable. 3) **Medium impact / Higher difficulty:** Cross-platform dev tooling support plan - Publish roadmap for Codex rebuild availability and supported platforms. --- ## 4) Communication Gaps (expectations vs reality) ### Recurring expectation mismatches - **“Agents will call tools when needed” vs reality:** 56% non-invocation implies users expect reliability that isn’t consistently delivered without special prompting/hooking. - **“Free credits means I can test the API” vs reality:** API key creation blocked by credit card requirement; x402 disabled on free tier. - **“Migration is straightforward and safe” vs reality:** repeated errors, unclear token detection rules, and reports of significant losses create distrust. - **“Marketplace skills are safe to run” vs reality:** active concern about malicious skills; security model not clearly communicated. - **“Image generation supports iterative edits” vs reality:** no consistency/edit loop, pushing creators off-platform. ### Documentation/onboarding gaps indicated by repeated questions - Migration legitimacy, deadline specifics, consequences of not migrating, and error resolution paths. - How to build a plugin to consume external APIs (DIaaS question repeats the need for a “plugin quickstart”). - Which branch to use and why (main vs odi-dev). ### Targeted improvements - Add a “Start Here (Cloud vs Self-host)” onboarding chooser. - A single “Tool/Skill Reliability Guide” with recommended patterns and when to use strict tool policy mode. - Migration runbook + status dashboard + receipts/audit trail. --- ## 5) Community Engagement Insights ### Power users and what they need - **R0am**: needs first-class support for enforced tool/skill invocation patterns and evaluation harnesses. - **Odilitime**: actively shaping plugin ecosystem and security; needs maintainable, standardized security pipeline and branch/release hygiene. - **0xbbjoker**: hands-on integration support (DIaaS plugins) and PR contributions; needs clearer plugin interfaces, templates, and review bandwidth. - **Stan**: Cloud implementation patterns; needs product alignment between Cloud UX and developer workflows. - **DorianD**: adoption-focused; needs frictionless setup, payment-free testing path, and autonomous agent UX. - **yojo**: creator workflows; needs image iteration consistency and account stability. ### Common newcomer questions signaling onboarding friction - Token migration legitimacy and “what happens if I don’t migrate?” - Staking/airdrop mechanics and timelines (frequent “stay tuned” responses increase uncertainty). - “Is plugin X working?” (e.g., Hyperliquid) suggests a need for a plugin compatibility/status matrix. ### Converting passive users into contributors - Create “Good first plugin” bounties: API consumer plugin template + examples (e.g., DIaaS trading signals). - Security contribution track: scanner rules, sandbox profiles, verified publisher program. - Run structured community test days for: migration UX, tool invocation reliability, Cloud onboarding. --- ## 6) Feedback Collection Improvements ### Current channel effectiveness - Discord is effective for rapid triage and peer help, but many issues get **redirected to support channels** without capturing structured root causes. - GitHub issues exist for strategic items (character/prompting, billing), but user-facing Cloud/migration problems are not consistently translated into actionable, trackable tickets. ### Improvements for more structured, actionable feedback 1) **Add standardized intake forms** (migration + Cloud billing/access + skill reliability) - Required fields: environment, wallet/provider, error codes, timestamps, screenshots, reproduction steps. 2) **Create a public “Known Issues + Status” board** - Reduces repeated Discord questions and consolidates updates. 3) **Instrument opt-in telemetry for developer pain** - Metrics: skill invocation rate, tool-call success, Cloud API key creation funnel drop-off, common migration errors. ### Underrepresented segments whose feedback is missing - Non-Discord users affected by migration (likely significant). - Non-Apple Silicon / Windows/Linux developers blocked by tooling constraints. - Non-technical creators who want iterative image workflows but don’t file issues. --- ## Prioritized High-Impact Actions (next 2–4 weeks) 1) **Ship a first-class “Strict Tool Invocation” mode** (productize the 3-step hook) + skill metadata linter to address the **56% non-trigger rate**. 2) **Remove Cloud onboarding blockers:** allow **API keys without credit card** (dev-mode quotas) and fix **Proton alias account duplication/merge**. 3) **Publish a migration runbook + known-issues status page + per-wallet receipts** to reduce loss reports, distrust, and support load. 4) **Define and implement a plugin security baseline:** signing/trust tiers + sandboxing roadmap; start with scanner + permissions model. 5) **Create an official “Plugin Quickstart + Templates” pack** (API consumer plugin, auth patterns, error handling) reflecting real usage (DIaaS, messaging, trading signals).