From nyxid
Assesses whether a goal on Aevatar is possible, its prerequisites, or why it cannot be done. Use before building to negotiate scope.
How this skill is triggered — by the user, by Claude, or both
Slash command
/nyxid:aevatar-feasibility-advisorThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Before you (or the user) commit to building something on Aevatar, answer three questions
Before you (or the user) commit to building something on Aevatar, answer three questions
honestly: Is it possible? What must be in place first? If not, why — and what's the
alternative? This skill exists so you negotiate scope up front instead of discovering a
hard blocker halfway through. It only advises — once a plan is feasible, hand off to
aevatar-workflow-authoring → aevatar-team-builder → aevatar-service-publisher →
aevatar-scheduler (see aevatar-platform-map).
Aevatar holds no third-party credentials and talks to no external service directly. Every external capability is brokered by NyxID. That single fact drives every feasibility answer below. It splits into two surfaces that people constantly conflate — get this right first:
| Surface | What it gives you | How it's used | Supported set |
|---|---|---|---|
| Connector (outbound) | Your workflow/agent calls a third-party API (read data, post, act) | nyxid_proxy tool (or a typed connector tool) with the service slug | Anything in the NyxID catalog (see below) — broad |
| Channel (inbound) | A third-party chat platform delivers user messages to your agent, which replies in that platform | An Aevatar channel module + NyxID relay webhook | Narrow — only platforms with a built module |
The trap: "I want a Twitter bot." A Twitter connector (
api-twitter) exists, so your agent can post/read tweets (outbound). But there is no Twitter inbound channel module, so you cannot have an agent that auto-replies to mentions/DMs the way a Lark or Telegram bot does. Same word, two very different feasibility answers. Always separate "call the API" from "be a bot on that platform."
You hold a NyxID bearer (~/.nyxid/access_token; base in ~/.nyxid/base_url, e.g.
https://nyx.chrono-ai.fun). Two read-only calls tell you the ground truth — make them with
the curl binary (a WAF may 403 Python HTTP clients):
NYX=$(tr -d '\n' < ~/.nyxid/base_url); TOK=$(tr -d '\n' < ~/.nyxid/access_token)
# What the user already has wired up (slugs you can nyxid_proxy right now):
curl -s -H "Authorization: Bearer $TOK" "$NYX/api/v1/services" # -> [{slug,name,...}]
# What CAN be connected, and exactly how (auth model + setup instructions):
curl -s -H "Authorization: Bearer $TOK" "$NYX/api/v1/catalog" # -> {entries:[{slug,auth_method,credential_mode,requires_credential,api_key_instructions,api_key_url,documentation_url,...}]}
(Inside an aevatar session with the nyxid MCP, the equivalent is the nyxid_services tool,
{"action":"list"}.) The live catalog is the source of truth — never assert a connector
exists or doesn't without checking it. The examples below are illustrative, not a fixed list.
requires_credential: true → the user must connect it before any call works.credential_mode: user + auth_method: bearer/provider_type: oauth2 → the end user
self-connects via an OAuth flow in the NyxID console (their own account). Low friction.
(e.g. api-twitter, api-slack, api-github, api-google, api-lark, api-reddit,
api-tiktok, api-facebook, api-microsoft.)credential_mode: admin (auth_method: api_key/bot_bearer/token_exchange/path) → a
token/secret must be supplied (often a bot token or an org/admin key), per the entry's
api_key_instructions + api_key_url. (e.g. api-telegram-bot — a @BotFather token;
api-discord-bot — a Bot Token; api-lark-bot/api-feishu-bot — token_exchange; the
llm-* provider keys.)api_key_instructions, api_key_url, and documentation_url are exactly what
you relay to the user as "here's how to connect it."api-twitter) + (c) run daily (schedule). Decompose into capability
classes before judging.| The user wants… | Possible? | Prerequisite / who must do it |
|---|---|---|
| Pure LLM / text / transform / branching pipeline | ✅ Always | Author a workflow (aevatar-workflow-authoring). No external anything. |
| Call a third-party API (read/post): GitHub, Slack, Google, X/Twitter, Reddit, a custom HTTP API… | ✅ If the connector is in the catalog | User connects the api-* connector in NyxID (OAuth for user mode, or supplies a token for admin mode — per the catalog entry). Then the workflow calls it via nyxid_proxy. |
| A connector that is NOT in the catalog | ⚠️ Only if it's a plain HTTP API | If it speaks HTTP + a supported auth_method, NyxID can add it (platform/admin work — not self-serve). If not HTTP, ❌. |
| Inbound bot that replies in-platform: Lark / Telegram | ✅ Yes | Connect the bot connector (api-lark-bot / api-telegram-bot) and register the channel (channel-admin / channel_registrations); NyxID provisions the webhook to Aevatar's relay. |
| Inbound bot on a platform with a connector but no channel module (Discord, Slack, X, …) | ❌ Not self-serve | Outbound calls work, but inbound-reply needs a new Aevatar channel module + relay wiring = Aevatar platform work. Offer the outbound-only version as the alternative. |
| Publish a workflow/team as an invocable service in-scope | ✅ Yes | Just bind it (aevatar-service-publisher). Usable within the user's scope immediately. |
| Have that service registered as a NyxID-brokered connector (callable by others/externally) | ⚠️ Host-gated | The host must enable external exposure (GAgentService:ExternalExposure: Enabled=true + RegisterAllPublishedServices or an opt-in policy). You cannot turn this on as a client — verify externalExposure on the service and, if empty, tell the user to ask the host. |
| Schedule a recurring run (cron) | ⚠️ Yes, with a binding | The scope owner needs a durable NyxID broker binding — i.e. an interactive console NyxID login, not just a CLI token. Without it, schedule creation 400s ("Authenticated NyxID owner binding is required"). |
| A service backed by an arbitrary custom agent / actor type | ⚠️ Constrained | Member implementations are workflow, script, or registered gagent kinds (GET /api/scopes/gagent-types). You can't point a service at an arbitrary actor; wrap custom logic in a workflow or script, or use a registered gagent kind. |
| A genuinely new service shape (e.g. streaming/WebSocket/gRPC endpoint, a runtime kind beyond workflow/script/gagent) | ❌ Not currently | Service endpoints are unary HTTP over the fixed implementation kinds. A new shape needs Aevatar platform work. |
| Exactly-once external side effects (e.g. "charge exactly once") | ❌ Not guaranteed | The workflow saga is at-least-once with idempotency keys. Require an idempotent connector endpoint, or do the exactly-once elsewhere. |
State these plainly when they bite:
aevatar-scheduler), never computed inside the workflow.delay/wait_signal events, not
busy loops. "Watch a feed continuously and react" → model as a scheduled run that polls.wait_signal/human-in-the-loop for long external waits).nyxid_proxy file artifacts cap at 100 MiB. Bigger downloads aren't feasible that way.<slug>. <credential_mode:user:
it's a one-click OAuth to your own account.> <admin: you'll paste a token — <api_key_instructions>;
get it at <api_key_url>.>" Then confirm with GET /api/v1/services that the slug appears.externalExposure block.Give the user a straight answer in this shape — never a vague "maybe":
api-github in NyxID
(OAuth, your account). After that I can build it as a workflow + schedule it."api-twitter connector), or an inbound bot on Telegram
instead. Want either of those?"Always: name the exact connector/prereq, say who must do it, and offer the nearest feasible alternative when you say no.
npx claudepluginhub chronoaiproject/nyxid --plugin nyxidEntry point and router for the Aevatar skill family. Teaches object model, auth, and caller modes, then hands off to the right companion skill for building, running, publishing, or scheduling on Aevatar.
Guides users step-by-step through building, scaffolding, testing, and deploying AI agents on GreenNode AgentBase. Invoke for any agent creation request.
Provides expert guidance for Azure AI Bot Service development including troubleshooting, architecture, security, and deployment patterns for bots using Direct Line, Teams, OAuth/SSO, and proactive messaging.